While building my homemade 6502 computer, I designed twin device based on Motorola MC6802 CPU. Designing hardware part was quite trivial task as both processors share many similarities. I was also able to relatively simply translate I/O routines to 6800 assembly. So at this point I can read keyboard and use serial port. I also plan to add TMS9918 video card, as in my main 6502 project.
Unfortunately there is major lacking element - software. When it comes to the 6502, there is EhBasic, which makes fantastic interface for retro computer. Unfortunately I was not able to find something like this for 6800. There are some historic examples of Basic interpreters for 6800 based computers, bot some of them do not even provide source code and if they do, there is no documentation or it is poor. So I do not know how to modify it to work with my computer. With EhBasic it is simple - just provide basic input and output routines for sending and receiving characters by UART or keyboard/CRT.

It there is no 6800 equivalent of EhBasic, I will be just as well satisfied by some monitor program. Anything that will let me to tinker with this device and test its peripherals.

https://www.corshamtech.com/tech-tips/basic-for-6800/ has a few options.

It seems there are some tiny basic interpreters around for the 6800... and some have available source as well:

https://deramp.com/swtpc.com/NewsLetter1/MicroBasic.htm

https://www.corshamtech.com/wp-content/ ... croBas.zip

_________________
Regards, KM
https://github.com/floobydust

Thanks. I tried to assemble this interpreter with AS02 assembler, which is recommended in description. Usually I use SB-Assembler for 6800 projects but unfortunately it doesn't work (at least without rewriting code) due to different conventions.
Of course I modified some definitions in code to fin my design.
In my device there is:
-16 kB RAM between 0x0000 and 0x7FFF
-4 kB "window" for 16 kB of paged RM between 0x8000 and 0x9FFF
-4kB of IO space and/or memory on expansion modules between 0xA000 and 0xBFFF. At this point the only important information is that there is MOS6551 chio at 0xA000.
-16kB of EPROM between 0xC000 and 0xFFFF.

So i set up following definitions:


Unfortunately resulting BIN file came out weird... It starts with single 0x39 byte at 0x0000. Then there is bunch o 0xFF up to address 0x3FFF. Then there are ASCII test strings and some random data, maybe part of the code? File ends at 0x4C9E. There is nothing at 0xC000 where in reality interpreter should be placed (at EPROM). What have I done wrong?
Also... I see in the code of MicroBasic interrupt vectors are not mentioned anywhere. I assume code was written to be loaded to RAM and because of that interrupt vectors were not concern of its author.

What I need to modify to make it work?

Unfortunately I can't help on that one... I don't have any 6800 systems, nor have I used the assembler mentioned. It would seem that there some org type statements that are defining addresses where the code goes. Also, when you say a BIN file... is it truly a plain BIN file or some specific format (like Intel Hex or other)? Does the assembler/linker have the option to generate any other output formats?

_________________
Regards, KM
https://github.com/floobydust

I have been told that this topic may be violating rules of this forum, because it is only about 6502. In my opinion 6800 is related to the MOS CPU (shared peripherals like ACIA or PIA, identical bus, very similar assembly language) but I do not want to violate any rules. So if this subject is problematic, I kindly ask moderators to remove this topic.

Anyway. I've been able to partially resolve original problem. It turned out that additional directives like "bss" or "page" were messing with code location. After their deletion addresses are fine.
This Basic interpreter probably had been written as an additional software for already working system, not its main "OS". Most likely it has been designed to be loaded to RAM or been executed from ROM by Monitor program. So there are no interrupt vectors or low level IO routines.
At this point I am trying to modify it further. I got working welcome/copyright message but after that computer freezes.

Current version of code can be seen here.

It's no problem at all for me. (There's just one person who sometimes takes a strong line on what's on-topic, and other times does as he pleases. The only person who can be definitive is Mike, and he only steps in for the most serious offences.)

It's true though that expertise here on the 6502 is widely held, but on the 6800 a bit more thin.

In any case, as you say in your head post, you've made a 6502 computer which is also compatible with 6800. That's interesting and on-topic in itself.

Ok. After taking closer look at this code I can only conclude that it was designed to run on top of some Monitor software.
There are hard-coded memory addresses in the code that doesn't appear to point at some I/O devices, but rather ROM/RAM locations.
For example:



I tried to experiment with the code, replacing some of that locations (that I suppose to be 16bit variables in memory) with may own declared variables in RAM, but I wasn't able to make it work.
I think that the easiest solution will be to start with some Monitor program instead of rewriting this Basic interpreter to work as a standalone piece of software.
Can you recomend me some easy to port 6800 Monitor? Preferably the one that this Basic was designed to work with.

Maybe Jeff Tranter has some resources... here's MikBug from Motorola themselves:
https://github.com/jefftranter/6800/blo ... mikbug.asm

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

If that BASIC is dependent on external routines, you can't just drop in any old monitor and hook it up; each monitor is different from each other monitor, sometimes vastly so.

I think that the easiest way to go at this is to do what amounts to fairly standard reverse-engineering job on this: start with the entry point to the source you have, walk through it until you find where it breaks, and then start writing the bits of code you need to make things work. I'm happy to help out with more details on getting that set up if you want to contact me via a private message here. (Actually, I already sent you one about something else.)

BTW, I have written a 6800 CPU simulator and machine-code unit test framework (found in here) that might be useful to you as well, especially if you're not highly confident in writing 6800 code that works the first time. The unit test framework also works for 6502, using py65 as the CPU simulator.


Well, certain CPU-specific expertise, yes. But in many areas 6502 systems expertise is also 6800 systems expertise because so much was inherited from the 6800 world, such as the bus design. Some might say even "stolen," given the propensity to directly use Motorola 6800-series parts (e.g., the 6821 and the 6850) and make almost exact copies of them (6520 and 6550).

That may be the reason that there's probably more 6800 systems expertise here than there is on anycpu.org.

And let's not forget that much 6800 work can be fairly easily ported to 6502 systems, to the advantage of the 6502 community. As one example, that unit test framework above, which would have been trivially ported from 6800 to 6502 had I not started from the other direction. :-) (Still, doing a 6800 version definitely improved the 6502 version as well.)

_________________
Curt J. Sampson - github.com/0cjs

Agreed, we can learn a lot from 6800 designs and software that's applicable to 6502, and vice versa.

And indeed, some kind of instrumented emulator is a good way to pick through the execution of some not-fully-understood software.

Uh oh! BDD alert! Whoop! Whoop! [Flashing lights.] :-)

Anyway, the simulator might be useful for that, but my intent was just that you could write a few unit tests describing the behaviour of the missing functions and then as you implement them get immediate feedback on whether your 6800 code meets those behavioural specs, rather than having to send the code off to run on the actual CPU somehow. (This is handy even for experienced programmers if your experience is that SBC uses a borrow flag, rather than a carry flag; it will catch little errors like this extremely quickly.) But of course anybody's welcome to use the code in any way they like, and I'm happy to help out to whatever extent I can.

_________________
Curt J. Sampson - github.com/0cjs

Ok, as for now:
1) I was able to port SMITHBUG monitor to run with my hardware.
2) I was able to use S19 file loader to load software to RAM.
3) I was able to port TSC MicroBasic and run it from RAM.
4) Unfortunately (despite info from comments) this interpreter turned out not to be ROM friendly. It contains some self modifying code, so it can't be executed from EPROM.
5) I tried to copy entire machine code of interpreter from EPROM to RAM and then execute it from RAM, but for some reason it is unstable (it freezes after "RUN" command).

Now I am looking for some ROM friendly interpreter.

There were several BASIC interpreters for the 6800 as far as I know.

* Microsoft BASIC for the Altair 680
* Robert Uiterwyk's 4K and 8K BASIC for the SWTPC 6800. I think the MicroBASIC you have is the 4K version. The source code for the 8K version may have been made available as well.
* Technical Systems Consultants (TSC) BASIC and Extended BASIC for FLEX
* PERCOM Super BASIC
* Compuware BASIC for the Smoke Signal Broadcasting DOS

Microsoft may be the best bet for something ROMable.



6800 code is not position independent. Did you assemble the code ORGed where it is to run or where it resides in ROM? I am surprised it got that far if the latter.