I pondered a bit about adding 6502 emulation to the Gigatron TTL computer. The 6502's instruction set is semi-orthogonal: first you handle the addressing mode based on the bottom 5 bits of the opcode. After that you jump to one of ~56 instruction handlers through a 256-entry jump table indexed by the entire opcode. You have to handle just a hand full of exceptions. The whole emulator should fit in less than 1K of 8-bits ROM code+tables this way. Quite some bit-juggling is required to emulate the P register, because the hardware can't store the ALU's carry-out (because of minimalism). But it can be dealt with: the Gigatron already emulates a 16-bit vCPU that runs all of its applications. The "v6502" can work in a similar way.

Implementation details aside, making a first version is relatively easy if we can accept a few shortcuts:

1. The stack runs in the zero page. Memory page 1 is already fully occupied by video, sound and system.
2. The zero-page is partly occupied: $00-$2f and $80 are used by the kernel loops. The rest is available.
3. No decimal mode
4. No interrupts. BRK will fall back to the Gigatron's own vCPU instruction set.

I hope I can do the slowest 6502 instruction in fewer than 130 Gigatron cycles including overhead. 130 cycles or 21 microseconds is the unused time between consecutive horizontal pulses of the VGA signal (which is software-generated by the TTL CPU). I expect the instructions will effectively run in lock step with this /hSync signal. This will give an overall speed of at least 24 KIPS in the fastest video mode. At least, on the stock system that runs at 6.25 MHz. We have overclocked boards to 12-15MHz using 74F logic instead of 74LS/74HCT.

It will exceed 50 KIPS if you ignore video generation completely, but that's not the idea now.

Any thoughts? Do the above restrictions and deviations still allow for a reasonable set of existing 6502 software to be run? Micro-Chess? Micro-Soft BASIC? Assume 64K is installed. Will the speed be bearable?

P.S: We could also run the stack in any other memory page. It's just page 1 that's really not available.

I have to say, 24KIPS is going to be *really* slow - about a tenth, or worse, of the speed of the common home micros of yore. It could probably be tolerated for running some simple BASIC programs, but a chess engine of any description is probably out of the question (unless it's scarcely more than a random-mover). And BASIC will undoubtedly rely on Decimal mode for printing variables, if not also line numbers.

You might want to take a real or simulated 65C02, and run your chosen software on it at that sort of speed (say 100kHz Phi2), just to get a feel for what's reasonable.

10% may not be too bad because there will be ways for improvement. Lock stepping with /hSync is just the simplest implementation. Micro-Chess doesn't have to beat Belle... I'll test it in VICE, thanks. But if Micro-Soft BASIC uses decimal mode, that certainly is a show stopper. I only quickly scanned it for SED but didn't see it.

What a great idea! Even a slow microchess would be nice to see.

I believe decimal mode is not used in MSBasic. (It was at one point used in one place in EhBasic, but that was fixed up.)

To be fair, some dedicated chess computers were made with very limited hardware - my family once had a Tandy 1450, which apparently was literally built around a 4-bit elevator controller-type microcontroller. The 1450 refers to the manufacturer's claimed ELO rating for the machine, the actual rating measured by subsequent collectors being substantially lower, and 1450 being decidedly unimpressive in the first place. But it was running in 4KB ROM, less than a kilo-nybble of RAM and with a 600kHz clock…

On the Gigatron, I suspect that code size will be less of a problem than execution speed. This means you can compensate for the inability to search deeply (even 4 plies / 2 moves will be a struggle at this level) by implementing a relatively sophisticated position evaluator. First check for mates or situations that make the move illegal, then add up material scores, add a factor for mobility (the number of pseudo-legal moves that can be made from that position), penalise doubled and/or isolated pawns, and penalise pieces that are attacked without being supported. Subtract Black's score from White's, implement a basic alpha-beta negamax search, and you have a basis for making not-completely-stupid moves at even 2-ply search depth, though 4-ply will add the ability to evade the simplest traps (at the expense of requiring more thinking time).

Interestingly, it seems that some of the strongest chess computers of the 1980s were built around a 6502 - sometimes with a large GAL whose function is unclear to me, but could include chess-specific acceleration functions. Today, the preferred platform seems to be a Cortex-M4 or M7 based microcontroller.

Are you sure? Which BASIC does this?

Sorry, but..



I also searched Apple1 Basic, the published msbasic sources, and BBC Basic 4... no sign of a SED or CLD...

There is a nice routine to convert binary to BCD using decimal mode (temporarily), but it looks like all the BASICs I've looked at might do it the divide by 10^N method.

As for emulating a 6502 on a Gigatron... It would be an interesting exercise - not that practical, but from the "if it's there, do it" department, then why not.. And using it - well, it will encourage efficient coding, if nothing else!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Good to know! We can safely assume that no evil mind covertly switches to decimal mode through PLP or RTI. There is a BCD-based floating point library out there, but I hoped none of the famous BASICs use that.

I have a skeleton for the emulator drafted now. It's a joy to see that many, seemingly arbitrary, opcode assignments play out well for the emulator. I found I can split the operand fetch phase from the instruction execution phase without extra effort. That greatly improves the granularity of scheduling between video pulses. Also the simpler addressing modes and instructions will take less time than the complex ones because of this. This breaks the lock stepping entirely. It can run faster than anticipated.

Apps in the original vCPU will be more efficient. But v6502 might not run that bad.

Back on the subject of Micro-Chess:

In common with most of the early, very small chess programs, it has only rudimentary support for the "special" moves and rules of the game. To castle, you must make two separate moves, and when the computer castles (only possible "from book"), you must manually enter the rook's part of the move. For en-passant capture, it is also necessary to move your pawn twice, and the computer cannot play the move on its own initiative. And it is not possible, through pawn promotion, to have two queens per side, making underpromotion mandatory in that case - and you have to do it by manually editing the board state!

I would therefore recommend that a chess program for the Gigatron be a more sophisticated one, which properly understands all the major rules and can enforce them on the player. This is not hugely difficult on a machine with a reasonable amount of memory, which the KIM-1 lacked.

Once our C compiler matures we can also compile MSCP and run it at 2 ply + quiescence search. There is a C64 compilation of it already, so I have no doubt it can be made to work.

I see "chess" as a possible by-catch of working on opening up the platform. For me it's not a goal by itself and definitely not something I'm willing to put direct effort in. While I have written, from scratch, six chess programs before, it's highly unlikely there will ever be a 7th.

As OP my interest is really centered around the question if the proposed imperfect 6502 emulation still enables interesting applications. Or is the proposal too crippled and will it therefore not be worth the effort? (Or does it just need some features reconsidered?) MicroChess and MS BASIC are just examples that came to mind.

P.S. Come to think of it, I can't think of other "must-have" 6502 apps yet. And we already have ports of WozMon and Tiny BASIC.. Any suggestions are welcome!

The proof of concept works. All of the addressing modes are implemented, and a fair amount of instructions as well. The v6502 interpreter runs in place of the standard 16-bits application vCPU. Switching between the two is a matter of modifying a zero page variable, so very fast.

Splendid! Of course the original killer app - VisiCalc - was first implemented on 6502. It's certainly a good question, as to what applications make sense and are attractive.

I have half of the instructions implemented now, and can more run a bit more complex programs. VGA timing seems to be ok. 8-bits Gigatron code is always a nice cycle puzzle. The hardest nut to crack is the overflow flag from ADC/SBC. Probably it's safe to ignore this as well, but oh well, it is in there now.

I did a more technical write-up on the Gigatron forum: https://forum.gigatron.io/viewtopic.php?f=4&t=128

I suspect the V flag sees more use than Decimal mode; it is relevant to signed integer arithmetic. You should see uses of the BVC/BVS instructions to test it.

Most uses in real life are after BIT, and emulating that is not as complex as signed overflow with ADC/SBC. Anyway, it's in now.