6502 emulation on Gigatron

[mvk]

First tests indicate an 8 times slowdown compared to the original NMOS. Not bad for half the transistors, and doing video and sound as well. Video link here: https://youtu.be/9jHlEjr7xJk

More than 2 times faster than the MOnSter 6502 (and that one doesn't do VGA and 4 channels of sound at the same time)

With a bit of luck, the cc65 C compiler can be retargeted for the platform at some point. Any advice from forum members is welcome, given the deviations described in the first post.

One application can be to write (part of) Gigatron applications in v6502 code. It is not as fast as the default 16-bit interpreter (less bang per buck), but the code can be more compact. Also, the implicit processing done by the addressing mode decoding still represents quite some value, if utilised for the right applications.

[Edit] Another idea is interactive programming with VTL02.

[drogon]

mvk wrote:

First tests indicate an 8 times slowdown compared to the original NMOS. Not bad for half the transistors, and doing video and sound as well. Video link here: https://youtu.be/9jHlEjr7xJk

munch.jpg

More than 2 times faster than the MOnSter 6502 (and that one doesn't do VGA and 4 channels of sound at the same time)

With a bit of luck, the cc65 C compiler can be retargeted for the platform at some point. Any advice from forum members is welcome, given the deviations described in the first post.

I'm in the midst of re-targetting cc65 for my own system - it's not plain sailing and there isn't much out there, but I have working code now, plan to do a write up soon though.

Quote:

One application can be to write (part of) Gigatron applications in v6502 code. It is not as fast as the default 16-bit interpreter (less bang per buck), but the code can be more compact. Also, the implicit processing done by the addressing mode decoding still represents quite some value, if utilised for the right applications.

[Edit] Another idea is interactive programming with VTL02.

Go for it

-Gordon

[barrym95838]

mvk wrote:

[Edit] Another idea is interactive programming with VTL02.

If you do, you should be aware that VTL02C is more efficient than the VTL02B currently posted at your link. I have shaved over 30 more code bytes from VTL02C since I uploaded that, but I haven't had the opportunity to thoroughly test my mods yet. My ultimate goal is to open up enough code bytes inside 1K to add another "feature", thereby creating VTL02D!

[JimBoyd]

barrym95838 wrote:

mvk wrote:

[Edit] Another idea is interactive programming with VTL02.

If you do, you should be aware that VTL02C is more efficient than the VTL02B currently posted at your link. I have shaved over 30 more code bytes from VTL02C since I uploaded that, but I haven't had the opportunity to thoroughly test my mods yet. My ultimate goal is to open up enough code bytes inside 1K to add another "feature", thereby creating VTL02D!

By 'more efficient' do you mean smaller, or is it faster too?

[barrym95838]

JimBoyd wrote:

By 'more efficient' do you mean smaller, or is it faster too?

Klaus did an informal test using his prime number program, and reported a 16% speed improvement from VTL02B to VTL02C. VTL02C also has "then" and "else" operators which allow conditional branches to avoid using the multiplication operator, and utilizing them increased the speed improvement to 25%. I know that one program isn't a robust sample size, but that's the only report available at this time.

I haven't profiled VTL02's interpreter on typical programs, but my suspicion is that it spends a large amount of its time parsing constants and branching, so improving the performance of those two activities ("cvbin:" and "find:") should provide the most satisfaction, for anyone interested in the attempt. Klaus made a "Speedy Gonzales" version that "pre-compiles" decimal constants to binary during program entry, but he had no intention of fitting his version inside 1KB like I did and still do.

[mvk]

barrym95838 wrote:

you should be aware that VTL02C is more efficient than the VTL02B currently posted at your link.

Great! I believe my simple emulator is feature complete now with respect to addressing modes, instructions and flags behaviour. It's slightly over 1K, but still less than 1200 words. Decimal flag is emulated in the P register, but ignored by ADC/SBC. I believe that's the expected behaviour judging from this visual6502 wiki page. Interestingly, I can't find any description about this specifically for the 6507 of the Atari 2600. My emulator is more a 6507 because there's no NMI/IRQ either. It still does have SEI/CLI/RTI.

I'l try wozmon first as a means to learn ca65, relocate its zero page variables and write and link the CHROUT/CHRGET routines. [Q: Is there a compile option where ca65 just spits out raw binary?] VTL02C will be after.

FYI, I got the VTL02B link through the Code tab on this forum. Moderators may take notice.

[drogon]

mvk wrote:

barrym95838 wrote:

you should be aware that VTL02C is more efficient than the VTL02B currently posted at your link.

Great! I believe my simple emulator is feature complete now with respect to addressing modes, instructions and flag behaviour. It's slightly over 1K, but still less than 1200 words. Decimal flag is emulated in the P register, but ignored by ADC/SBC. I believe that's the expected behaviour judging from this visual6502 wiki page. Interestingly, I can't find any description about this specifically for the 6507 of the Atari 2600. My emulator is more a 6507 because there's no NMI/IRQ either. It still does have SEI/CLI/RTI.

I'l try wozmon first as a means to learn ca65, relocate its zero page variables and write and link the CHROUT/CHRGET routines. [Q: Is there a compile option where ca65 just spits out raw binary?] VTL02C will be after.

FYI, I got the VTL02B link through the Code tab on this forum. Moderators may take notice.

You need to assemble then link as 2 steps:

Code: Select all

ca65 --cpu 65c02 -l woz.lst  woz.s -o woz.o
ld65 -t none -S 0xF000 -vm -m woz.map -o woz woz.o

ca65 outputs relocatable format (even if you have a .ORG in the source file), then ld65 takes this to prodice the final output file. The -S 0xF000 specifies the start address. The output file will be raw binary that you then need to load at the right address.

(you might not want the --cpu flag though - all that does is allow for the 65C02 opcodes).

-Gordon

[barrym95838]

I am certainly not an Atari 2600 programmer, but I have heard that every conceivable feature and trick available on the 6507, including decimal mode and unofficial op-codes made it into many of the games.

(Sorry for wandering off-topic ... it's easy for me to get carried off on tangents ...)

[mvk]

[I always believed the 2600 didn't have decimal mode.]

Anyway, after fixing some inevitable bugs I managed to run the original wozmon on the Gigatron. The computer already comes with a built-in WozMon, but that's a rewrite in its own instruction set with extra features (such as backspace).

This is the real Apple-1 wozmon, running in 6502 land. This means you can also stuff 6502 opcodes in memory and run them with R.

Of course I needed to patch the memory mapped I/O. Source here. Changes I made are:

1. Relocate page because $FF00/$7F00 map in screen memory
2. Relocate zero page variables
3. Replace KBD with some 6502 instructions that peek at the serial input register instead
4. Replace DSP with vCPU code that can draw characters and scroll the screen
5. Replace the `Blank' separators with a small shift, so that output doesn't wrap around the small screen

Basically, it is an Apple1 clone now.

P.S. I really didn't emulate the `@' cursor (yet?). For the screenshot I typed one...

[barrym95838]

The screen font doesn't look quite "genuine", but that's a very minor nit to pick, so congratulations anyway!

[mvk]

barrym95838 wrote:

The screen font doesn't look quite "genuine"

Neither does the VGA plug look genuine. But seriously, it's the Gigatron's own font that is already in the ROM image. I would rather have that `@' cursor as well, even if it doesn't flash. But I haven't figured out how to do that in a simple way.

The patches to wozmon are modest, IMO, and all unrelated stuff is kept at their original offset.

With a tongue in the cheek we can call this an Apple-1 emulator. But any original software will need relocations and some patching.

Online emulator here: https://marcelk.net/gigatron/apple1/. Remember to type letters in UPPER case!

[BigEd]

A splendid development! I've taken the liberty of posting in the Retro Computing Forum.

[mvk]

While on a fever I went overboard and

1. Let the Apple1 mockup remap the Gigatron video a bit (it's software-defined after all). Short story is that wozmon routines are now visible at their standard location in $FFxx even on the 32K system.
2. An '@' sign is displayed while waiting for input, flashing at 1Hz with a 75% duty cycle
3. Keyboard input is mapped to upper case automatically, and that also maps DEL to rubout ('_')
4. All DSP/KBD mockup code is moved to page 3, making the entire input buffer $200..$27F available
5. Even more of the original wozmon bytes are restored to their authentic value.

All for vastly improved retro experience. And oh, something like

Code: Select all

0.FF

is much faster than on the original system.

I'm tempted to support

Code: Select all

E000R

as well, at the expense of some screen area, but VTL02 should go first.

[mvk]

oscarv (KIM Uno) visited tonight, and as a result we have Microchess code running on the "Apple-1" replicated with 34 TTL chips.

[mvk]

Somebody took notice