Tangerine Microtan 65 - 6502
pullmoll
Posts: 817
I thought I should post what I've done, just in case my HD crashes...
Actually I could use some help fixing the q6502 core I wrote. The machine I'm trying to emulate is the Microtan, a very simple 6502 computer. The CPU core is based on MAME's 6502 implementation, which is actually a 6510. The 6510 has only a few really invalid opcodes and a lot of rather obscure opcodes. The C64 demo folks certainly know them.
Anyway, the current state is this: The code seems to start up the TANBUG in ROM, which prints a TANBUG logo in the last line and scrolls the screen. Then an empty line with a cursor is displayed and the screen is scrolled again.
The first bug to find is why the 2nd half of the screen gets filled with 00s (square glyph) instead of the contents of the rows below. This could be due to an error in indirect addressing or the INC/DEC opcodes. I haven't disassembled the code to see how the scroll loop is done.
The screen memory is 512 bytes at $200..$3ff, which gives an amazing 32x16 character resolution. Each character position has a 9th bit associated with it that tells, if instead of text a block graphics should be displayed. If this is the case, a 2x4 block graphics consisting of 4x4 size poxels (= 8x16 font size) is displayed. The "graphics" resolution thus is 64x64 pixels.
The graphics mode is enabled by reading $BFx0/4/8/c and disabled by writing $BFx3/7/b/f, where x = c/d/e/f, i.e. incomplete decoding of the address lines.
The ROM and the character generator are included. If you put the MICROTAN.CHR on the SD, it will be loaded. This isn't necessary as the default font is hard coded in the VGA driver.
There currently is a waitcnt(clkfreq/256) in the fetch opcode loop, so you can see how the display is scrolled. You can remove it in q6502.spin if you fix the bug
Enjoy!
v0.1.2: Add keyboard support. You can enter commands into Tanbug now.
v0.1.3: Included support to load *.M65 files. A few are included. Unfortunately all games require a PIA setup connected to some digital (Atari) Joystick, which isn't emulated yet.
v0.1.4: The scrolling bug vanished after I tried to add debug code to m6502. Is the output of Tanbug giving the command "LC000,0" supposed to be as slow as it is?
v0.1.5: Fixed the slowdown. It was caused by not clearing the IRQ when the interrupt was taken. Probably a missing acknowledge for the keyboard interrupt!?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 6/3/2010 5:17:52 PM GMT
Actually I could use some help fixing the q6502 core I wrote. The machine I'm trying to emulate is the Microtan, a very simple 6502 computer. The CPU core is based on MAME's 6502 implementation, which is actually a 6510. The 6510 has only a few really invalid opcodes and a lot of rather obscure opcodes. The C64 demo folks certainly know them.
Anyway, the current state is this: The code seems to start up the TANBUG in ROM, which prints a TANBUG logo in the last line and scrolls the screen. Then an empty line with a cursor is displayed and the screen is scrolled again.
The first bug to find is why the 2nd half of the screen gets filled with 00s (square glyph) instead of the contents of the rows below. This could be due to an error in indirect addressing or the INC/DEC opcodes. I haven't disassembled the code to see how the scroll loop is done.
The screen memory is 512 bytes at $200..$3ff, which gives an amazing 32x16 character resolution. Each character position has a 9th bit associated with it that tells, if instead of text a block graphics should be displayed. If this is the case, a 2x4 block graphics consisting of 4x4 size poxels (= 8x16 font size) is displayed. The "graphics" resolution thus is 64x64 pixels.
The graphics mode is enabled by reading $BFx0/4/8/c and disabled by writing $BFx3/7/b/f, where x = c/d/e/f, i.e. incomplete decoding of the address lines.
The ROM and the character generator are included. If you put the MICROTAN.CHR on the SD, it will be loaded. This isn't necessary as the default font is hard coded in the VGA driver.
There currently is a waitcnt(clkfreq/256) in the fetch opcode loop, so you can see how the display is scrolled. You can remove it in q6502.spin if you fix the bug
Enjoy!
v0.1.2: Add keyboard support. You can enter commands into Tanbug now.
v0.1.3: Included support to load *.M65 files. A few are included. Unfortunately all games require a PIA setup connected to some digital (Atari) Joystick, which isn't emulated yet.
v0.1.4: The scrolling bug vanished after I tried to add debug code to m6502. Is the output of Tanbug giving the command "LC000,0" supposed to be as slow as it is?
v0.1.5: Fixed the slowdown. It was caused by not clearing the IRQ when the interrupt was taken. Probably a missing acknowledge for the keyboard interrupt!?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 6/3/2010 5:17:52 PM GMT
zip
298K
Comments
edit: I need not have scratched my head so hard just noticed you have the wiki link there that says exactly that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
We have a probably similar institution over here in Bonn. My liq^H^H^Helectronics shoppe is P+M Elektronik. I've been going there since I was 8 or 9, so that was mid 70s, and the shop existed (perhaps long) before. I got an electronics experimenting kit for christmas. I don't remember what I bought. It was something I ruined on that kit (Cosmos Electronic).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/18/2010 5:30:58 PM GMT
In the Hydra section, there was a NES emulation that emulated the 6502.· It may/may not be useful to you on this project.
http://forums.parallax.com/showthread.php?p=871551
--trodoss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
The first transistor I used to play with was a White Spot. I think it was that situation, of having just one transistor, which started my habit of scrounging and then using everything over, and over ....
My father wanted to get me off of valve stuff, I should have stuck with them, there's good money in bottle amps now.
Transmitters had a few of the giant jam jars, so all was not lost
Wan't the Mirco tan something to do with Elektor?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Thanks! The NES didn't have a 6502, but a N2A03. Very similar, and yet different in many regards. Most importantly it had no decimal mode.
No, what I need is a clue at the code that is going wrong. I found the function that does the scrolling:
So for some reason the second part with lda $0320,x and sta $0300,x goes wrong. I don't yet know if the 00s are read or written. I have to trace that piece of code.
Edit: I didn't even know that STA ABS,X doesn't do a page wrap when LO(ABS)+X > $ff. This isn't the cause of the problem, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/18/2010 7:14:31 PM GMT
I don't think so, or otherwise the Wikipedia article would have mentioned that fact.
The Elektor had an even earlier, pre-microprocessor project to run games. I don't remember the name of that thing. It was too expensive anyway with dozens of TTLs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Just goes to show that there were so many clones/variants to the 6502.
Here's hoping that the next one is the Apple ][noparse][[/noparse] [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
I never got on with 6502 etc, I was too locked into Z80 (thoughtwise, and moneywise
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Henry's sold white spot ones as well as the red spots. The white spots were intended for IF amps, IIRC, the red spots were AF only.
I always preferred the Z80, as well. It made a much better embedded controller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
It's a variant of the 6502 with a MMC, PSG, Timer and some extra opcodes.
Then I have done two 6502 cores for my SID-player.
My experience with 6502 emulation is as follows:
If you have an error in your cpu emulation, it's 90% certain to be an addressing mode issue.
Now you mention it was a red spot that I had. When I wanted another they had stopped stocking them in the Half width shop in Bristol and were supplying GET45, I think, I bought an OC71 but it was nothing better than a noise generator.
The GET45 was so leaky that it was self biasing, with a couple of coils, and nothing else, I had a 100KHz osc. The youth of today just do not know how much things have progressed ( and I'm "only" 52 )
My father had some MATxxx transistors which were ok to 150MHz, at that time, I think that they were still a bit "militry" then. I wasn't allowed to use them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Yep, that was one of Aaron's goals: a universal disassembler. I used it to disassemble the Microtan code fragment. It has an impressive list of supported CPUs:
Signetics 2650 is among the CPUs what Forth is among the programming languages. I can't understand how anyone can understand its weird addressing modes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Perhaps, yes, though I suspect the memory handler that dispatches on reads from the frame buffer range. Unfortunately I'm rather drunk now and even worse is that I ran out of coffee, so no chance to fix it tonight
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
The 2650 could be clocked all the way down to DC which was a notable feature at the time. At the time the local electronics store "TechniParts" IIRC sold them for $26.50 which was also quite cheap, nothing like the 32-bit ARM chips now with internal memory for $1 (in 2010 $) though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Hmm.. perhaps it was the Junior Computer, while I thought it was an even earlier video game system without a CPU. Some years ago I still had the issue where it was described.
I wrote an 2637 video driver for an Arcadia emulation in C some time ago. Fun stuff.. The Arcadia could probably be "propelled".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
I just read about this machine, and got an answer to something that has bothered me. On some computers, other devices like graphics chips can access the memory without interrupting the CPU. This was true on Apple and CoCo, for example, but not true on C64 / Atari. I never did hear a solid explanation for why that is the case, when it's clear those devices can operate, leaving the CPU at full speed. Atari and C64 machines are slowed considerably when the user requests the more advanced graphics features. Was this cost of RAM, or something else?
Anyway, this is kind of a cool old computer, and I'm excited to see a 6502 build up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I think by cost potatohead meant the expense of time or CPU cycles it takes to have more complicated graphics.
I can only speak for the Atari 800 and its ANTIC chip (and GTIA). They also used the 6502 clock state where the CPU puts nothing on the address or data bus to fetch the video RAM data. Writing to the video RAM or display list was thus asynchronous to the ANTIC fetching the same data and could be flicker-free.
The Colour Genie OTOH had Z80 wait states inserted by the CRTC accessing memory, so it would become a little slower if you increased the number of characters per line. The character generator RAM was not synchronized, so writing it caused flicker (tiny white dots) spread across the display, which was a major refutation for animated graphics.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The wrong data in the 2nd screen half during the initial scroll is still there and I couldn't find out where it comes from. It's not the data returned by the io.spin code.
When entering commands, the TANBUG always only prints a ? after the command, which probably means it didn't understand the command.
The commands from the Wikipedia Tanbug page seem to work. The hex dump is exceptionally slow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/22/2010 3:19:15 PM GMT
Either the LDA abs16,X ($BD LL HH) or the STA abs16,X ($9D LL HH) opcodes are wrong, yet they are so simple.
The sequence of subroutines (vector) for the first is
rd_abx_p = read absolute plus X, with page wrap adjustment, into alu stores X in XY calls calc_abs_xy_p which reads the opcode word at PC, adds X and allows the result to be in the next page calls rd_byte to read to alu m_lda = store alu in A and set N and Z flags accordinglyThe second opcode is handled by
m_sta = store A in tmp wr_abx_np = store tmp in absolute plus X, no page wrap adjustment stores X in XY calls calc_abs_xy_np which reads the opcode word at PC and adds X to the lower byte only (page wrap) copies tmp to alu calls wr_byte to write from aluSomewhere along the code execution alu is damaged (set to $00), but only for the 2nd half of the screen memory ($300..$3ff), which is very odd in itself, since there is just one handler doing both.
I verified that reading $300 to $3ff through the I/O handler actually returns the screen memory contents and not $00, so I assume that either A is destroyed by fetching the next opcode, or that the store does it under certain circumstances. Also writing to the screen using the io_command and io.spin handler works as expected.
I posted it on the previous page already: the code that causes the bug to manifest itself:
The opcodes at $FA43 and $FA46 are the ones that fail.
The almost identical loop, except for the abs16 values, at $FA3A does work. What the heck can cause a bug dependency on an absolute address?
Anyone willing to take a look at my code?
Could I trace this kind of code with one of the Spin/PASM debuggers?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/22/2010 3:31:44 PM GMT
*
Yep, that was one of Aaron's goals: a universal disassembler. I used it to disassemble the Microtan code fragment. It has an impressive list of supported CPUs: including TMS1000
**
Who can tell me who has accessed the TMS1000 to dump the code and use disassembler ?
I am looking at a TMS1000 in a Hornby Zero One train controller that used the TMS1000 in the 1980's. Would like to update with some minor changes onto a new processor.
Comments welcome
Charlie
I don't know if this has happened. According to the author of the tms1000 CPU core it is incomplete and not very well tested. It was capable of running a calculator example code from some technical manual, though.
I have no idea of the requirements to do this, sorry.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects