Apple 2 Monitor running on SBII

[Thomas]

Recently, I found a piece of software on cassette that was part of a conversion of Apple 2 ROMs for the Superboard. I remember taking the ROM binary and convert the absolute addresses to a location in RAM. Later probably it got lost, due to errors while saving and reading from cassette.

Surprisingly the Apple 2 Monitor ROM conversion seems to be working fine. It requires a SBII with 32x32 screen and 32k of RAM. It stays at $7800 to $7FFF and the RESET entry point is $7F59.
Attached the cassette hexload file and the 1977 redbbook reference. All the standard entry addresses are unchanged (keep in mind that addresses moved down from F800+.. to 7800+...)

Try out the debugger, that was only present in the first Apple ROMs. You can step your code also in ROM areas. Load and save of code is working as well to the standard ACIA serial port.

enjoy

[Mark]

Thanks for recovering your file!
It was the original Apple II F800 system ROM that included paddle reading, cassette I/O and Basic support.
It seems the mini-assembler is part of the F000 ROM, not part of this one.

I wanted to see how Apple handled tracing into ROM without 6502 hardware mods, so I found a disassembled listing of the original Apple II ROM on the 'net. Later I incorporated your C1P changes into the assembler source file, and then modified it to be compatible with OSI540 video. You did a good job inserting OSI specific code in place without altering much of the original ROM!

What I ended up with is a version that can be assembled with the A65 Macro assembler to create the original Apple version, your Superboard version, as well as a version that will run on a C2/C4 system.

Anyway the answer appears to be the ROM instruction is copied into RAM before being executed. Special treatment for JSR JMP, RTI, RTS and branch instructions. Its a pretty neat feature, & doesn't take much space. I see it also installs an IRQ handler for the Apple Break key to recover from a running program which could work on OSI if added.

Attached is the assembler source as well as a C2/C4 OSI65V monitor loadable file which uses 2K at $5800 and executes at $5F59 (to fit in a 24K system)
Simply change the .org line in the source & assemble to relocated it to any other address. The 65V (.lod) file is created automatically by A65.

[Thomas]

Hi Mark,
great job, this makes the A2 monitor available to the Ohio product family. And I think it is worth, as the debugger is pretty cool to use on a real C1P.
As mentioned, the A2 Basic part was corrupt and not usable, so I decided to look for source code files on the integer BASIC.
Attached the source code for the Macro Assembler I'm using and a binary compiled to 4000, to match to your 24k Monitor.
Still, something is not right, as Integer Basic starts (4000 cold start) and allows entering text, but the code seems not to be stored. A wrong command will give a correct Syntax error response, but that's all.
The Macro assembler I'm using is this one.

ASM.PNG (48.54 KiB) Viewed 17277 times

But converting this to A64 should be relatively easy. Maybe you have more luck, to get it run correctly. The stack area is of concern, as it overlaps with the OSI vectors. Also, the move of the input buffer to 0230 instead of the original 0200 maybe an issue.

[Mark]

I found Michal Kowalski's sim6502 and followed the trail of newer versions.
Eventually I found the most recent versions updated by Daryl Rictor.

I updated the program to support OSI 65V, 65A and MOS checksum file formats to more easily produce files for OSI.

I haven't looked into what is going on with the Apple code yet. But I thought I'd make this available to anyone who wants it.

See sim6502 on my Tools page.

Cheers,
-Mark

Sim6502 binary I/O

sim6502.gif (36.71 KiB) Viewed 17185 times

[Thomas]

Seems to work great. I very much like the Opcode preview on the right with examples and explications, when entering code.
One problem I noticed, on saving the assembled code as binary. In the older version, you could choose a range option like:

code.jpg (31.03 KiB) Viewed 17176 times

Now this option field is gone and the full 64kB of data is saved instead, without limiting to the actual code. All other file types consider the code range, but not in case of binary.
Please have a look.

[Mark]

The binary options save dialog has been reenabled. The problem has to do with the default version of the common controls used by MFC's CFileDialog on newer OS's not supporting templates. Forcing Vista compatibility reenabled templates.

Find the update here.

Thanks,
-Mark

[Thomas]

Just another observation with the newly compiled version.

code.jpg (33 KiB) Viewed 17156 times

The memory view window behaves erratic. Binary data shown does not match in address to the compiled data. Also the block adaress does not start on even 16bytes intervalls.
2nd, would it be possible to preset the address range for binary data saving to the compiled data range, and the manual stays for manaul adjustment, if needed.
Thanks Thomas

[Mark]

I've made a few more changes to Michal Kowalski's 6502 simulator.
The Document & Disassembly view sizes are restored to previous sizes, the debugging windows now move when the App windows moves in addition to following the minimizing & normal viewing of the App, and the binary Save options dialog is prefilled with the program range as requested. Additionally the memory dump views now show graphics characters in the OSI font. The memory dump width now maxes out at 16 characters per line, and will go to 8 before wrapping on smaller values. This makes the starting addresses consistent for larger widths.
I plan on making more OSI/UK101 specific changes in the future.

I wasn't able to recreate the memory view vs compiled data difference. Could it be due to different source views having been opened & compiled & closed while the memory view was opened? It may have a disconnect between a MDI program and single view debugging windows. If you can demonstrate the steps to show the problem that would be great.
Anyway I thought I'd put this version out now & see how it works.
Find it at here on my OSI Tools page.
Cheers,
-Mark

6502 Simulator

sim6502.jpg (287.18 KiB) Viewed 17140 times

[Thomas]

This last update provides a lot of good improvements, especially that view sizes are restored to previous location and size.
Also, the memory dump view works nicely. Concerning the memory view vs compiled data difference, this was my mistake as the start address in the memory dump view was so odd. There was actually no difference in memory view vs compiled data.

Nevertheless, one observation for improvement is the start address in the memory dump view (seems to be always $0000). It should start at the start of the compiled data, when the view is opened the first time.

In my opinion, the Michal Kowalski's 6502 simulator has a lot of good potential, to become a OSI specific compiler and debugger.
A second tool I'm using is the KickC - Optimizing C-compiler for 6502 platforms (see https://gitlab.com/camelot/kickc/-/tree/master). For the UI, I'm using an old IDE called JFE (Jen's File Editor) which allows to create sophisticated batch commands to call other tools or gadgets. I use it to call my WinOsi emulator via arguments, so the compiled code can be immeadily executed by the emulator.
This makes using C++ for the C1P a lot of fun, although KickC does not support a floating-point library and does occupy the whole zero page. But there are workarounds.

P4.JPG (47.72 KiB) Viewed 17133 times

Looking forward to more interesting news on the 6502 simulator.
Thomas