OSI Basic

[epaell]

I've just updated my system with the dual ROMS. I've set one up for the 6809 (bank0=ASSIST09; bank1=Extended BASIC) and the other for 6502 (bank0=SMON; bank1=Microsoft BASIC (OSI) - a fine 1977 vintage! ).



The version of BASIC I used was from Grant Searle's page: http://searle.x10host.com/6502/Simple6502.html. It's already set up to work with a 6850 so all I had to do was change the start address of the code and the location of the 6850 for MECB. Oh, I also had to change three lines because the source code had negative 8-bit numbers defined but cc65 didn't seem to like these. This is also very odd because Grant also used cc65 to compile this version of BASIC - perhaps something changed between the version he used and the one I have.

I'm having a bit of confusion with my cc65/ld65 that I don't fully understand (which made this process take way longer than I had anticipated). The code has a fairly standard thing where it defines where in memory the BASIC software will be compiled for (a start address) and then a second definition for where the vectors go (right at the end of memory space). For some reason, despite the listing showing everything where it should be, the binary that is generated seems to have a large gap between the two and so when I burned it onto ROM things were clearly in the wrong spot. It quite possibly boils down to user error.

[epaell]

Ah, actually, I think it has to do with the "config" file that ld65 uses - I probably need to change some things there to match my current memory map. I'm used to just having to do this with "org" directives but this seems to be a bit more involved.

[epaell]

Indeed, it seems that I had to set the size and location of the ROM in the config file. That then correctly formed the binary file. I'd have to admit that I find it very confusing that the generate bin file can be different to what is shown in the listing file.

[Editor]

Ah, actually, I think it has to do with the "config" file that ld65 uses - I probably need to change some things there to match my current memory map. I'm used to just having to do this with "org" directives but this seems to be a bit more involved.

Yes, indeed. When I was porting the SMON code across for cc65, I retained the .org mainly for backward compatibility / readability.

With the cc65’s advanced linking, it is necessary to use SEGMENTs to define where the assembled code should be linked.

Therefore in my SMON updates you’ll note a SEGMENT declared prior to each .org, and each segment configured in the ld65 .cfg file, that is specified on the command line. e.g. I have a CODE segment and a VECTORS segment etc. (from memory).

[Editor]

Indeed, it seems that I had to set the size and location of the ROM in the config file. That then correctly formed the binary file. I'd have to admit that I find it very confusing that the generate bin file can be different to what is shown in the listing file.

Agreed, it is confusing at first, but this is the added complexity of having full linker capability.

Certainly and added pain for direct assembly (I had to define a ROM segment, and bodge a $00 byte at $8000, just to force a 32KB binary ouput for a full 28C256 ROM image for SMON), but it does makes sence for the full 6502 C compiler capability of cc65.

[Editor]

I've just updated my system with the dual ROMS. I've set one up for the 6809 (bank0=ASSIST09; bank1=Extended BASIC) and the other for 6502 (bank0=SMON; bank1=Microsoft BASIC (OSI) - a fine 1977 vintage! ).

An awesome idea, to use the different banks / ROMs to make code avaiable for alternative CPU Cards!

You just now need a rotary coded switch to make your bank switching easier!

[epaell]

An awesome idea, to use the different banks / ROMs to make code available for alternative CPU Cards!

LOL, of course my brilliant plan will break if (when) the Z80 and 68008 boards come into being ... though, that's a first world problem I'd be happy to have I guess I'll just have to partition the ROMs and designate the first two switches for the CPU selection and the other two for the functionality required In reality though, the 68008 will probably want a fairly decent amount of ROM in the first place (those 16-bit instructions chew up space quite quickly). Of course an even simpler solution is to build another ROM card for this purpose (and this time I'll add ZIF sockets)!

[epaell]

I'm on a roll with this new fandangled GitHub thing. I've uploaded the changes to OSI BASIC for the 6502 over here:

https://github.com/epaell/MECB/tree/mai ... /osi_basic

As with the SMON version, the build creates three versions for different ROM configurations (and adjusts the location of the I/O appropriately). It basically uses the same configuration the Greg made for SMON.