Modular 6502 SBC with emulated CPU, ATMEGA16 based

[cbscpe]

Hi Klaus,

reading the MBR, the Partition Table and Root-Directory and then select a file and read it is a very simple task and takes only very little code. I've never done it in AVR assembler but in 6502 code I have done it several times and it takes about 1500bytes of code. Also I was thinking about the virtual 6502 to do that and not the AVR.

My initial proposal for the ATMega162 was really only to have the extra pins and not to use the external memory interface so you can activate all pin options in one configuration. However after I read your concerns regarding the external memory interface I have thought about using it and came to the following conclusions

- only use 8-bit addresses of the external memory interface, the higher address bits will still be connected to a port, so to access a byte you just set the port to the high byte and use the low byte as an index to the external 256byte address space, as soon as you use an address above the internal RAM the external memory interface is activated, so which high-order address you use during external RAM access is a don't care as long as it is larger than the internal RAM. This gives you paged but unsegmented 64k address range
- timing is not really critical. In other projects I use a 74AC573 and a 70ns SRAM and that's fast enough for zero wait states.
- the good thing about external memory interface is you don't have to manually setup the READ and WRITE signal they are handled in hardware.
- also IO can be accessed using the external memory interface and they take advantage of the READ and WRITE signal as well. By using a different high-byte address in the access you can even have the ATMega162 create wait-cycles for IO but not for Memory.

I must admit that I have not looked at your code at the moment so I cannot tell if there is a penalty regarding execution time.

Regards

Peter

[Klaus2m5]

Peter,

we agree on a file system software to be in the emulated machine, not the emulator itself. However, the boot loader and boot image managment is part of the monitor/debugger, which is not in the emulated machine's RAM space. The User of the emulated machine has unrestricted access to each and every byte in the 64k address space.

The big advantage of the external memory interface is the extra free IO-pins on the AVR. You can see that with Daryl's project, although he is using internal RAM and flash-ROM only: http://sbc.rictor.org/avr65c02.html . He gets a little more than 2MHz emulated 65C02 speed, but with a 24MHz clocked AVR. This is about the speed ratio to be expected using the external memory interface if you can get away with zero waitcycles. The external interface is by design 1 cycle slower, even without additional wait states.

Quote:

- the good thing about external memory interface is you don't have to manually setup the READ and WRITE signal they are handled in hardware.

This is not such a big advantage as SRAMs have a mode of access, where the -CS and -OE signal can be left active while only the address lines need to change. While -CS is tied low I only switch -OE off for IO or for a store or modify type of instruction. Instructions requiring a write to memory are much faster than on a 2MHz 65(C)02 anyway.

cheers, Klaus

edit: quoted the wrong statement.
edit2: clarify use of -CS for SRAM

[cbscpe]

Hi Klaus,

Regarding the READ and WRITE signals for SRAM I think we are not talking the same thing. I rather thought about using the /RD and /WR from the external memory interface to all external devices (SRAM, VRAM, IO) and have an /CS for each individual device and by addressing different regions you can produce short /RD and /WR pulses for SRAM and longer for IO. Typically the /CS for SRAM would be active all the time as in your case except when accessing IO or VRAM.

But that was just thinking and I fully agree with your points. At the moment I have decided to use your concept of Address-, Data- and Control- Bus. One difference will be that I plan to use a ATMega1284P so I can use the additional flash as the repository for the various boot images and boot loaders. And perhaps I can overclock it to 24MHz/25MHz so the emulated 6502 will have the performance of a 3MHz 65C02.

Regards

Peter

[cbscpe]

Hi Klaus,

I have come up with the following additional hardware to get some more IO pins.

Upper Address Bits Latch

Address-Latch.png (4.86 KiB) Viewed 8633 times

Then instead of setting the address with the following instructions

Code: Select all

            out   abuslo,pcl        ;opcode fetch
            out   abushi,pch

I use

Code: Select all

            out   abuslo,pch        ;opcode fetch
            out   PINB, one         ;toggle address latch clock
            out   abuslo,pcl

of course this requires an AVR processor that supports the toggle function when writing a 1 to a bit of one of the PINx registers. As I use a ATMega1284P, this is the case. This uses one additional cycle for all RAM accesses but on the same time the ATMega1284P supports a clock of 20MHz which more than compensates for the extra cycle. And your code is really squeezing the last cycle out of the emulation. So it is still very fast.

Regards

Peter

[Klaus2m5]

Peter,

nice idea! Maybe I will convert all loads to the address bus into a macro to allow an easier change of this function.

cheers, Klaus

P.S.: I am currently on vacation, so I may respond late during the next 6 weeks.

[cbscpe]

Hi Klaus,

thanks. No need to hurry, enjoy your free time.

Regards

Peter

[jim30109]

I've been digging around for several weeks trying to figure out just how I want to approach a build and have to admit that I keep coming back to this design. Having a monitor running "on top of" the "processor" sounds like something that would save me from huge amounts of frustration. Years ago I wrote a fair amount of 6502 and Z80 assembly code and never had a decent set of debugging tools to help me. (Building a real-time data acquisition system based on the Z80 involved a lot of erasing and reprogramming EPROMs over the span of several months.)

When I was younger, that seemed kind of fun. These days, I think I'd find it frustrating.

Thanks,
Jim

[Klaus2m5]

Version 0.84 is now available with new major features. First there is an optional MMU with 512k of RAM. Second there is an optional IO subprocessor based on an ATMega16 allowing access to its timers, IO ports and IO units. Multiple IO subprocessors can be added.

These features and a change to the way the processor handles decimal mode led to a higher flash consumption. The use of the larger ATMega32 is now mandatory from this version on. The version 0.83c for the ATMega16 will stay available in the "low flash" branch on GitHub and bugfixes will continue to appear if necessary.

[6502user]

I am trying to carry out your 'Modular 6502 SBC with emulated CPU, ATMEGA32 based' in the most simple version: only the atmega32, the memory. and the serial terminal. The assembler builds the code correctly. The code load on the AtMega32 is carried out with the fuses established according to the instructions in the manual. But when I start the emulator it takes some time and then the following message is prompted on the serial terminal:

N6502 Emulator V0.84 built Nov 22 2022 17:42:08
LCD reset failed
IO subprocessor @ BF70 failed, cannot continue!

I've had a look at the code, but it's a bit hard and I can't find a way to avoid the interaction with the LCD and the IO subprocessor.

Please, how could I modify the code to achieve this?

[6502user]

Klaus2m5 wrote:

The version 0.83c for the ATMega16 will stay available in the "low flash" branch on GitHub ...

My knowledge of English is not good. I can't figure out what the "low flash" branch on GitHub is about. At least I can't find that version. Please, could you put a direct link to it?

[6502user]

In case it helps anyone, I have found how to inhibit the reset of the LCD and the subprocessor.

1.- Modify the 6502_Emu_IO.inc file so that those two calls are not executed:

;*** custom IO resets go here ***
........
........
;rcall lcd_rs ;reset character LCD
........
;io_modules_reset ;defined by a macro in 6502_Emu_config.inc

2.- Modify the 6502_Emu_config.inc file so that setting is not done:

;**** IO select for builtin modules ****
......
.......
; enable LCD module and define IO select signal for LCD, disabled if undefined
; .equ lcd_sel = 13 ;IO select register 1, pin 3
.......

3.- Reassemble all

In this way the monitor runs continuously and although at the moment it does not respond to enter command mode.

This is what I can see on the serial terminal:

0.100 0.0000 00 x00 y00 NV-BDIZC Reset

N6502 Emulator V0.84 built Nov 25 2022 23:03:58
0.1FF 0.FFFF 00 x00 y00 NV-BDIZC H>
0.1FF 0.FFFE 00 x00 y00 NV-BDIZC H>
0.1FF 0.FFFD 00 x00 y00 NV-BDIZC H>
0.1FF 0.FFFC 00 x00 y00 NV-BDIZC H>
0.1FF 0.FFFB 00 x00 y00 NV-BDIZC H>
0.1FF 0.FFFA 00 x00 y00 NV-BDIZC H>
0.1FF 0.FFF9 00 x00 y00 NV-BDIZC H>
....

and so on.

[BigEd]

6502user wrote:

I can't figure out what the "low flash" branch on GitHub is about. At least I can't find that version. Please, could you put a direct link to it?

Github is a web interface to git repositories, and in a git repository you find not just the current state of the code, and not just the history of the changes in that code, but you also find that there can be several branches of the code. Usually a branch is a previous state of the code, sometimes a previous state that's had some subsequent fixes or developments.

In this case, there's the main branch, and there's a branch called "low flash". You can browse the code in the low flash branch here:
https://github.com/Klaus2m5/AVR_emulate ... /low-flash

When you're browsing a particular branch, you can use the green "Code" button to download a zipfile of the code from that branch. It might be that this link will automatically give you that zip file:
https://github.com/Klaus2m5/AVR_emulate ... -flash.zip

Hope this helps.

[6502user]

Thanks BigEd.

Now I understand that about the low_flash and the github's branches.

[6502user]

Hi, all.

I have the impression that this topic, because it is from three years ago, is no longer dealt with.
In case someone could help, I'll tell you about the difficulty I've encountered:
Although I have used Putty and TeraTerm properly configured, the <CTRL><M> key combination, which is supposed to correspond to <CR> or 0x0D in these terminal emulators, does not allow me to activate command line mode. It is presenting messages out of control, as I indicated above.

[GARTHWILSON]

6502user wrote:

I have the impression that this topic, because it is from three years ago, is no longer dealt with.

Projects on this forum can go many years; so things do stay relevant. Besides, someone may come in years later and find it and want to take up the same project, and have questions about it, and may even cause the originator to get interested again and take it further, and add to the topic.