• Please review our updated Terms and Rules here

Does anyone have a 6809 emulator written in Pascal?

Ruud

Ruud

Veteran Member
Joined
Nov 30, 2009
Messages
1,984
Location
Heerlen, NL
I now own this nice 6809 SBC built by Fred Jan Kraan. But its monitor is lousy IMHO so I want to write a new one. At the moment I use the real hardware but I won't have access to it all the time. So I thought about writing my own emulator. I could begin from scratch but why inventing the wheel again. I googled but nothing so far.

Does anybody have a pointer or the sources?

Thank you in advance!
 
I have a 6809 native debugger that supports tracing, disassembly and inline assembly. Other useful commands like memory display and such. Tracing can trace through ROM code (copies the instruction to RAM to exec it.) Not an emulator. It runs on the 6809 hardware. I wrote it for Grant’s Six Chip 6809 computer where it was ROM resident. Just needs system specific key in/char out routines. Can load Intel Hex and SRec data but currently expects it to come via the console because that’s how I used it.

Reasonably well tested but possible you’ll find a bug or two. I also ported it to run on a CoCo 2.

If you want to hack on it I’ll send you the source. I built it using an open source 6809 assembler on macOS but it runs on any Unix as far as I know and maybe Windows?
 
Also, it needs 8kb but could probably be slimmed down to 4k with some work by removing expression processing and other commands you don’t need.
 
Well, I have converted some CPU emulators from one language to another - so I can't see why a 6809 emulator couldn't be converted to Pascal (if one doesn't already exist).

But why (necessarily) in Pascal - unless that us your preferred language?

I did quite a lot of work with the 6809 SuperPET emulation for VICE using a homebuilt emulator. I used a 6809 validation package to check it out.

Dave
 
dwgumby said:
.... I wrote it for Grant’s Six Chip 6809 computer where ....
Click to expand...
Oops, it was so obvious for me that I forgot to mention it should run on a PC.

shattered said:
https://github.com/aladur/flexemu is written in C++ and MAME (also a C++ project) has a driver for original Microkit 6809 -- https://github.com/mamedev/mame/blob/master/src/mame/multitech/mkit09.cpp
Click to expand...
Thank you for the pointers, they can be of help.

daver2 said:
But why (necessarily) in Pascal - unless that us your preferred language?
Click to expand...
It indeed is. In 1985 I had the choice to learn either C or to continue with Pascal that I learned at school. Only when Linux became popular I regretted that decision a bit. I made some efforts to learn it later but what put me off was that one program written with Turbo C did not compile with GCC or CodeBlocks. Or programs written with CodeBlocks didn't compile with GCC. Quite stressing IMHO. So I stuck with Pascal.
I have already written emulators for the 6502 and Z80 so why not another one? :)
 
I started off with Z80 assembler and migrated to Pascal as my preferred language also.

When the Amiga came out, it was a small step to learn Modula 2.

I did, eventually, secumb and learn 'C'. I found a relatively transportable subset of 'C' at an early stage though.

If you are looking to port an existing 6809 emulator into Pascal, there are various degrees of 'rubbish' out there to start from. I used one in my porting of the SuperPET, and found out it was rubbish... Another one was much better, but still failed the validation suite. This was a relatively trivial fix though.

Dave
 
Ruud said:
Oops, it was so obvious for me that I forgot to mention it should run on a PC.
Click to expand...
No problem. I hadn’t looked at the actual board info yet to see it had no serial port.

Enjoy the 6809. It is a really fun, capable little 8 bit CPU.

Dave
 
This makes me want to drag and drop my Java 6502 simulator into one of the AIs and say "Convert this to Pascal and, oh, 6809 instead of 6502". See what kind of dogs breakfast gets spit out.
 
This is unfortunate and frustrating, because I've solved about half each of your "want a 6809 emulator that runs on a PC" and "want a better 6809 monitor" problems, but it's all done in Python, and so therefore useless to you. :-)

More seriously, I've been dealing with similar problems for a while, so what I have right now is:

1. Frameworks for CPU simulation and unit testing assembly code, in my t8dev project. Currently the CPU simulation supports 8080, 6800 and 6502, but much of this work (including probably many of the 6800 opcode implementations) can be re-used for 6809.

2. A reasonably decent yet small (under 2K ROM, under 64 bytes RAM) monitor, tmon, ported to 8080, with a fairly full set of unit tests that are fairly easily portable to implementations for other CPUs. (Some tests, e.g., examining memory, can be extracted to a more generic level and used just as they are: typing an examine command and making sure the correct data are displayed is not at all CPU-specific. Other tests, such as ensuring the registers are saved and reloaded correctly, are system specific but can be parametrized so that most of the test code can be generic and just the register definitions need to be specified separately for each CPU. I already have done this for other software; one example is the first four tests of a 6800 "qdigit" routine here that just directly import generic tests from here.

Writing the 6809 simulator and porting tmon to 6809 has been on my long-term to-do list for a while now (I have several 6809 machines which also have lousy monitors.) So I don't mind moving that up to a "current priority" project if there's someone around who wants to help with it.

If you want to have a play with tmon and see how the testing framework works, you can clone my 8bdev repo on to a Linux machine and type ./Test -E .build/obj/exe/nec/pc8001/exprom1.bin. You may have to go a couple of rounds of "get informed what additional system packages you need to install" (nothing particularly weird, and all available on virtually any Linux distro) and re-run the Test command, but eventually you should see a NEC PC-8001 emulator pop up with that extension ROM added; you can type CMD TMON and you'll be in the monitor ready to play. (That command will change to just MON at some point.)

If you're interested in working on this, drop me a PM and we'll sort out the next steps.
 
  • Like
Reactions: zu2
cjs said:
This is unfortunate and frustrating, because I've solved about half each of your "want a 6809 emulator that runs on a PC" and "want a better 6809 monitor" problems, but it's all done in Python, and so therefore useless to you. :-)
Click to expand...
IMHO Python is better readable then C so it it is welcome!
 
daver2 said:
It depends who writes the 'C' of course...
Click to expand...
And who writes the Python!

My Python is not dead-on PEP-8 "standard" style, but is very much designed for readability if you're willing to learn a few conventions. (In fact, the hardest thing most developers find to learn is, "think about the other folks reading your code, not on rules designed to avoid thinking.") Anyway, that's, as is true for pretty much any system, just a part of the various conventions and ideas you learn by working with others on the code.
 
OK, I decided to write my own emulator. One good reason to do it: it forces me to understand every opcode thoroughly. If I don't understand an opcode, how can I emulate it the? I also noticed I started not using some opcodes for the simple reason I don't understand them enough.

I started with generating a binary file that contains all possible 6809 opcodes, using pascal of course:
Code: 
  for b1 := $30 to $33 do               { lea. }                           
   begin
    for b2 := 0 to 255 do
      if (b2 <> $90) then
     begin
      write(fb, b1);
      write(fb, b2);
      if ((b2 and $8F) in [$88, $89, $8C, $8D, $8F]) then write(fb, 0);
      if ((b2 and $8F) in [$89, $8D, $8F]) then write(fb, 0)
     end;
   end;

Then I tried to disassemble it with my disassembler only to find out that it needed some more tweaking. Next step is to test my assembler on the generated opcode to see if the result is the same as the original binary. If not, I have to check the the disassembler, assembler and generator until all work in harmony. As backup I have another assembler that enables to make a cross-check.

Edit: Wow, that went smooth: "no differences found".
 
You must log in or register to reply here.
Back
Top