Hi Peter,

The code is not redundant. There are two separate uses of the zsav pair. In bootloader.asm, I set zsav to 0x3600 and then call xmodem1. That reloads both the emulator code and the default ROM image. Calling xmodem will set zsav to 0x4000 and will just load a ROM image.

I hope that is understandable.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Hi Klaus,

yes but I want to make sure that a registers definition can only be used within a certain range to avoid using registers that are already in use. So by using .def and .undef I can make sure that I can use only the currently active definition.

Regards
Peterr

Hi Daryl,

thanks for pointing me to the difference, I completely missed the 1 in call xmodem1

Regards Peter

Hi Daryl,

I have a question, I downloaded the AVR_CC65.zip and had a hard time to get makeavrr.bat work (I had to change the commandlines for AR65 and CA65, the versions I recently downloaded behave differently than the bat-file expects, e.g. CA65 expects a file name after -l and the AR65 does not like wildcards when adding modules, perhaps it's also due to my lack of Windows know-how). But now as the batch makeavrr.bat runs without errors I don't find the expected ROM Image. Or what do I need to do to get the image now? The BATCH file merely creates the avrr.lib and nothing more. Sorry if I ask a stupid question, but I'm completely lost.

Regards

Peter

Hi Peter,

CC65 is not easy to get set up. Did you follow the directions in the Installation Instructions.txt file explicitly? Did you install the CC65 files in "C:\CC65", or are they in another location. Did you also download the CC65 source files? My batch files expect everything to be in the right place. You should not have to run makeavrr.bat directly. copyavrr.bat will copy all files to the right place and then it will call makeavrr.bat.

The idea is that the "CC65-avr-RAM" folders are the original source files and they stay in the CC65 folder. The copyavr.bat file copies these to the libsrc folder and then runs the makeavr.bat file to compile the library. It also moves the library file, header files, startup .o file, and cfg file to proper folders.
If you run makeavr.bat from the original source folder, it will not work as the file are not located in the libsrc folder. I hope that makes sense.

I have attached a screen dump of my C drive with CC65 expanded. The red arrows show the required folders. You only need to run the copyavr.bat and copyavrr.bat file to build the libraries. Once that is built, you can compile your own C source files using the new libraries.

For example. After creating the RAM library, open the ascii folder in the AVR Demo folder and run the make.bat file. it will compile the program and create an "ascii.ram" file. This is the file you download to the AVR. It will load at $400.

Let me know if this helps. If not, can you email me some screen shots of your folder layout?

thanks!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Hi Daryl,

I did as described, and on purpose used the same directory (c:\cc65. So except for the changed commandlines in the .bat files ("ca65 -l %%i" does not work, it gives a "missing input file" error in my case "ca65 -I %%i.lst %%i" works). I also was able to compile/assemble everything in avrr as well build the library (although here as well needed to change the command line for ar65 to get it work).

But I think I did not express myself sufficiently, with ROM Image I though now I was able to create the SBC Monitor from scratch, but as I understand now what is in CC65-avr-ROM/RAM are rather the IO Routines used by the SBC Monitor and so I need to download the monitor source code first and then compile this against the library. So I need sbc2os.zip and unpack it into the tree at c:\cc65.

Is that correct?

Regards

Peter


P.S.: I have now a modified version of the Emulator that allows me to address external RAM added to the ATMega1284p similar to the RAM that Klaus has added to his ATMega16, only that I use a 74HCT574 latch to store the upper memory addresses, this makes it slower, but on the other hand leaves me with more free IO Lines. In any case my goal is to port it onto a Arduino Mega r3 with a QuadRAM. Then I can use the real external memory interface.

Hi Peter,

The SBC2OS Monitor was designed with all the IO built-in. It uses TASS as the default assembler. You could use another assembler, including CA65, but you might have to modify the source files to use CA65 syntax. If you do that, then you should be able to assemble the monitor without using a target device. In other words, since all the IO is built into the monitor, just use CA65 to assemble a working binary. I have not used ca65 to do that, so cannot help you with the process. I'm still puzzled as to why you needed to modify the batch files - they should work as is, as long all you have the cc65 files all in the right places.

Email me if you want to discuss it further. Its sbc at rictor d0t org.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Daryl,

I went on looking for a 6502 emulator for AVR and quickly found this thread. I read through it and saw your page - great job indeed!

The reason I started to look for this is the fact that some smart people have recently managed to "hack" out

http://e4aws.silverdr.com/hacks/6500_1/

the content of 6500/1 based chips, which are 6502 based microcontrollers. Now I'd like to push towards a true replacement for those chips, using an AVR running native 6502 firmware code.

There is one question though, which I think wasn't discussed - you wrote once that you monitor the 6502 cycles but don't use them for anything. Since in the 6502 times many time-critical routines were implemented using "cycle counting timers" :-) to many applications it would be more important to have accurate cycling than maximal speed.

- Is there a feasible way to make your emulator run "cycle-exact"?
- Is there a feasible way to map the RAM/ROM/IO ports in the same way as the 6500/1 does?

Actually I don't have anything against having more RAM/ROM available but all ROM, RAM and IO ports must be present in the expected places. If anywhere beyond that - that's "nice to have". Obviously welcome :-)

Thanks for your time,

Regards.

Anything is feasible. It would not be hard to add code back into the emulator to count the cycles emulated. Then it would just be a matter of using a 16 bit timer to count actual AVR cycles and build a compare routine to throttle the cpu execute code. It will definitely cost you on emulated speed, however.

As far as re-mapping memory, again it is feasible. However, the more complex the memory map, the more AVR time it takes to read or write the address, again slowing down emulated speed.

I'm not sure of the target speed you are looking for, but it could be difficult to even get 1MHz speed with the changes you are requesting.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I made 1541 disk drive emulation using a PIC that is cycle exact. I made the instruction fetch emulation a timer interrupt. When the interrupt occurs I look up the instruction to emulate and after the instruction emulation I then store the cycle time for that instruction into the timer compare (PR1 for the PIC), and then exit the interrupt. There is about 7 PIC instruction cycles of overhead associated with the interrupt handling. I original didn't use an interrupt and just busy loop'd waiting for the timer compare int flag, but I found it more convenient to just use the interrupt and I could then handle everything else (VIA emulation, LCD, etc.) in the main loop. This let all of those sub-cycle issues work properly. You could do the same thing with the AVR. I am using a 70MIPs PIC, but it actually works with a 16MIPs PIC (CPU emulation only).

The 1541 memory map is very complex:

0000-03FF - 2K RAM
1800-180F - VIA1
1C00-1C0F - VIA2
C000-DFFF - ROM 1
E000-FFFF - ROM 2

Doesn't look too complex until you realize that every single memory location not shown above is either a mirror of one of those locations or just a the upper byte of the address. So, every single memory location has to be mapped properly to handle programs that deliberately access mirrors as part of copy protection. With some creative bit testing you can test the main (correct) locations first and then traverse through the more complex mirrors afterwards. This really helps speed up the process. The good new is that most all of the 6502 instructions that access memory are 4us+. With a 16MIPs part that gives you 64 CPU instructions, which is enough even for the worst case. I found with my emulation that it takes 14 to 37 PIC instruction cycles (not including 7 cycles for the interrupt overhead) to emulate any instruction (best case to worst case). I still needed time left to handle the VIAs and data separator which is why I went with a 70MIPs part.

Hi guys,

I'm running the 65C02 emulator with a 16 MHz clock and I have changed the bit rate to 9600 bps. When I run the AtmegaI receive on the terminal:

*********************************
AVR 65C02 Emulator
By Daryl Rictor (c) 2013

Press Enter to Start System
Press 'U' to upload new ROM image

That's right, then I press Enter (and indeed the terminal only sends the character 0x0D), but instead of receiving:

Version 3.1 - Starting Emulator...
.

65C02 Monitor v5.2 (6-28-13) Ready
with Enhanced Basic Interpreter (c) Lee Davison,
FIGForth, and MicroChess (c) Peter Jennings
(Press ? for help)
>0300.3FF

, what I receive is 608 bytes of ASCII characters equvalents to the 0x80 and 0x00 values, like this:

80 80 00 00 80 00 00 80 80 80 80 80 00 80
00 00 80 80 00 80 80 00 80 80 80 80 80 00 80 80 00 00 80 00 00 00 80 00
80 00 00 00 00 80 80 80 00 00 00 80 00 80 80 00 80 80 80 00 80 00 00 80
00 80 80 80 00 80 80 00 80 80 80 00 80 00 00 80 80 00 80 80 80 80 80 80
80 80 80 00 80 80 80 00 80 00 80 80 80 80 80 00 00 80 00 80 00 00 80 00
00 80 00 00 00 80 80 00 00 80 00 80 00 80 80 00 00 80 00 80 80 00 00 80
00 80 80 80 00 80 00 80 00 00 00 00 00 00 00 80 80 00 80 80 80 80 00 80
80 80 00 80 80 00 80 80 80 80 80 00 00 80 00 00 00 80 80 80 80 80 00 00
80 00 00 00 00 00 00 00 80 00 00 80 00 80 80 80 00 00 00 00 00 00 80 80
80 00 80 00 00 80 00 00 80 00 80 00 00 00 00 00 80 80 80 80 00 80 80 00
80 00 00 80 80 00 80 80 80 00 00 80 00 80 80 80 80 00 80 80 00 80 80 00
80 80 00 00 80 80 00 80 00 80 80 00 80 80 80 00 80 00 80 80 80 00 80 80
80 00 80 00 00 80 00 00 00 00 80 80 00 80 80 00 80 80 00 80 80 80 00 80
00 00 80 00 00 80 00 80 80 00 80 80 80 80 00 80 00 00 80 00 80 00 00 80
80 80 00 80 00 80 80 80 80 00 80 00 00 80 00 00 00 80 00 80 00 80 80 00
80 00 00 00 00 00 80 80 80 00 80 80 80 00 80 00 00 00 00 80 80 00 80 00
80 80 80 00 80 80 80 00 80 80 80 80 00 80 80 00 80 00 80 80 00 00 80 00
00 00 80 80 00 00 80 80 00 80 00 00 80 80 80 80 00 00 80 00 80 80 00 80
80 00 80 00 00 00 80 00 80 00 80 80 00 00 80 00 00 80 80 00 80 80 00 80
80 80 00 80 00 00 80 80 80 80 80 00 80 00 80 80 80 80 00 80 80 00 80 80
00 80 00 00 00 80 00 80 00 80 80 00 80 00 00 00 00 80 80 80 80 00 80 00
80 80 80 80 00 80 00 00 80 00 00 00 80 00 80 80 80 00 80 00 80 80 00 80
80 80 00 80 80 00 80 80 80 00 80 80 00 80 80 80 00 00 80 00 00 80 00 00
80 80 00 00 80 80 80 00 80 80 00 80 80 00 80 00 00 80 00 00 00 00 00 80
80 80 80 00 00 80 00 00 00 80 80 80 80 00 80 00 80 80 00 80 80 00 80 00
80 80 00 00 80 00 00 00

Please, must be I load before any file o something is going wrong?

Diego

Hello Diego,

Can you confirm you changed the baud rate in 2 places? The first is in the bootload.asm file around line 180 and the second is in the avr6502.asm file around line 86. From your capture above, it appears the bootloader is set to the right baud rate, but after you press enter, the avr6502.asm re-initializes the serial port. its possible that is why you are getting the unexpected response.

if you did program both, then we need to look at your terminal settings. be sure echo is turned off and no line feed after carriage returns.

Thanks for trying out my Emulator!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Thanks a lot, Daryl.

I'm sorry, I didn't change the baud rate on bootload.asm.

I did that now, but then the initial message it is wrong also.

I found a solution, setting again 0x0C in your mentioned files:

, and reassembling all again. This way enable to receive right messagess, but I can't understand why [*].

Finally, running at 24 MHz, I have seleted 0x4D as setting for 19200 baud rate.

The serial communication is going well at 19200 baud.

[*] Now I know why that was right (The ckdiv8 fuse setting was 0, and not 1, as would correspond to the indicated low fuse 0x0C value. Having set it to 0, it divided the external 16Mhz clock by 8, which for a UBRRL = 0x0C, made the baud rate 9600). Now the ckdiv8 fuse setting is 1, the external clock is 24Mhz and UBRRL = 0x4D, resulting a 19200 baud rate. Everything is fine now and according to your instructions.

Now I raise another tougher issue:

Would it be possible to drive a VIA 6522, through the available ports of the ATMega1284? In other words, that an instruction STA 0xABCD, #27 would enable two ports as address bus (AB high addr, CD low addr, respectively) and another port as data bus (#27).

And provide the system with an external memory?

Diego

Glad you found the problem!

You could do that, but the speed would be really slow, unless you want to re-write the emulator read and write routines.

Take a look at klaus' system. He is using external RAM and it may be better suited for your needs.
viewtopic.php?f=8&t=2407

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/