It's likely that is is mostly just the standard Microsoft Basic with some modified I/O routines. Since Microsoft Basic is now under the MIT license you are free to modify the code, it may be relatively easy to re-implement the I/O routines and have a legal 'recreation' of the P2305 cartridge.
This particular machine is Z80 based and not 6502, so it's not trivial to port.
I've looked into building my own BASIC implementation and got quite far with that. Unfortunately, most games that were written back then rely on timing that is near impossible to recreate at that level. Emulating cycle exact Z80 behavior and then having the original BASIC routines on top of that is a far easier route.
Well Woz was pretty good at software too. He wrote a lot of the early Apple software, including Integer Basic (to write games) and the low level disk software, called RWTS for Read/Write Track/Sector.
I'm not good at this at all, but if you do want to thank people that helped you, and let them know what it meant to you, don't leave it too late. I've had one regret after another as people who were significant in my early life died and I didn't get the chance to let them know what they meant to me.
It has 32-bit registers, but it has a 16-bit ALU, so it's a matter of opinion if that makes it a 16 or 32-bit processor. I'd go with 32-bit in that it's instruction set gives the impression to the programmer that they are working with a 32-bit system.
And for more evidence, the Z80 is referred to as an 8-bit processor but has a 4-bit ALU.
The 68000 actually had three 16 bit ALUs, so could munch a peak of 48 bits per clock cycle. Only one could do all operations while the other two were basically just add. These days we would say there were part of the AGU (address generator unit) but one of them was shared with the data register operations.
For some of us it brings back bad memories of sitting watching progress bars for hours and occasionally getting asked to feed another disk into the drive. Office was probably the worst for the number of floppies, but linux was even more, and you had the extra worry of if it would actually boot after the install, or if you got a setting wrong and had to start again.
Soon after all that we got to use CD's, which made life a lot better.
> bad memories of sitting watching progress bars for hours
Bad? Nah. I would use the words "exciting or "annoying" as it was annoying to wait but exciting as you were edging closer to playing with new software.
HOWEVER: if the act of installing software over and over again all day long was your job, then you have my condolences :-)
The shop I worked for, back in the day, got some of the technicians parallel ZIP drives. It was a godsend to copy the Windows 95 CAB files to the hard disk drive from the ZIP drive and run the upgrade from there, versus feeding the machine floppies.
If you were really luck you were working in a site w/ Novell Netware and you could just copy the CAB files down from the Netware server. >smile<
Not at all the same, but they did have QuickDraw II for the IIgs. This library had the benefit of using the simpler IIgs graphics modes, avoiding all the Apple II weirdness. With a little bit of searching the source can be found online.
For anyone wanting to build sprite type code on the Apple II, you really should read this article in Byte magazine:
Preshift-Table Graphics on your Apple
by Bill Budge, with Gregg Williams and Rob Moore. A23
Move blocks of pixels across the screen with only 3K bytes of overhead
It's kind of hard to find, it's in the December 1984 Byte magazine, but an additional magazine at the end of the PDF, Bytes Guide to Apple.
At the time this was huge, Bill Budge was probably the most well known game programmer, so getting a look inside how he wrote code was a big thing.
Of course, as mentioned elsewhere, graphics is hard on the Apple II because of the complex memory layout due to Woz wanting to save a few chips. This can be contrasted with the Atari and Commodore computers that had custom chips that made graphics a lot easier.
I've implemented both UPnP discovery and mDNS, and mDNS was quite a bit easier to make reliable than UPnP. However, if they did have a reliable UPnP system, it would almost certainly destabilise the software for any transition like this. There's just so many different network issues to deal with, it's tough to debug when a user reports a problem and it's probably an issue with their router which is only sold in Germany. It is very frustrating class of bugs, when the app just doesn't find devices on the network.
