GS/OS and ProDOS block devices

5 posts / 0 new
Last post
CaveNerd's picture
Offline
Last seen: 12 years 6 months ago
Joined: Oct 10 2004 - 17:56
Posts: 17
GS/OS and ProDOS block devices

I've built a homebrew ATA controller for my II systems - according to my research, it should boot (the appropriate version of) ProDOS perfectly on just about any II within reason. My GS-3 boots every version of ProDOS I throw on it, impressively fast considering how simple the design is. Trouble is, GS/OS won't boot.

Now, currently the conditions are:
1. I haven't finalized the ROM code yet, to make it non-slot-dependent - currently it only works in slot 7.
2. I've written a generic ProDOS block driver for it, which simply maps 65535 blocks to the lowest 16 bits of LBA sectors.
3. Partitioning hasn't yet been under consideration.
4. GS/OS booting from 3.5 floppy can see the darned thing!
5. Recently the last rev of the ROM was written to support second drive, and to save/set/restore the emulation bit upon calling the block driver.

Currently my concerns are:
1. Partitioning - is it necessary?
2. Will GS/OS refuse to talk to me until I have a SmartPort ROM implemented?
3. A boot driver? Is there one for a generic block device? Will I have to write one? :o
4. Are ScsiHD.driver and SCSI.Manager working against me?
5. Is my problem caused by something stupid, like it won't boot from slot 7, or stupid stuff like that?
6. Am I still too much of a n00b on the 65C816, like is there more I have to do than set the emulation bit (like changing bank regs or something)?

Now I'm a really old hand with the II systems, but never having a GS until recently, I'm new to GS/OS, and having only a 3.5 to boot from is a bummer - hence this project. Problem is, knowing so little about GS/OS is convincing me that I don't know enough to answer my own questions. I may have to boot trace through the stinking thing or tear apart the boot block to see if I can figure out what's wrong.

Anyone have any ideas? Or perhaps want to lend a hand? Just for a credit though - I plan to publish this project in full to the general public when it's done, not to make money. Zero budget nerd wants to help other zero budget nerds, etc. - anyone who knows how to solder and has a small supply of parts and a TTL book or two ought to be able to duplicate my design easily. Even now it should be totally suitable to give to the II*,II+,//e crowd, but goshdarnit I want the thing to be complete before I do that.

* yes - I know, as long as the II in question has had its ROMS replaced with Applesoft ROMS and has a language card.

Offline
Last seen: 6 years 9 months ago
Joined: Dec 20 2003 - 10:38
Posts: 249
Rich Dreher has a project tha

Rich Dreher has a project that uses hard drive or compact flash and still has boards available. Where this may help you is that his project is open source and you can download The firmware and schematics on his site:

http://dreher.net/?s=projects/CFforAppleII&c=projects/CFforAppleII/main.php

Partitioning is necessary to those who have drives larger than 32Meg and want to use all of the drive. GS users will say yes.

What makes a card bootable is a good question. There is one byte in the firmware that must have a specific value or the Apple II's won't see it as a bootable device. Once again, Rich has all that info.

I have Rich's CFFA card in my IIplus with his latest firmware and I boot from slot 7.

Hope this helps,

Vince

CaveNerd's picture
Offline
Last seen: 12 years 6 months ago
Joined: Oct 10 2004 - 17:56
Posts: 17
checked that out before...

...but I didn't notice firmware listings. I'll check it out.

The original Apple II+ Autostart ROM looks for a signature of 5 bytes, C0x1=$20, C0x3=$00, C0x5=$03, and C0x7=$3C. Later versions only care about 4, but as it happens I've chosen to stick to the 5-byte signature, which has two effects:
1. Should boot on a II+ (or II with ROM Language card, Autostart ROMS)
2. Won't be recognized as a SmartPort device by later ROMs (C0x7=$00).

Or are you telling me about a different byte for later ROMs? That's not really where I'm stuck - the bootstrap loader for ProDOS is perfectly happy when I type C700G. GS/OS just crashes, apparently as soon as sector 0 is loaded to page 8 and executed.

I would love to have a CFFA card (have noticed it a number of times), but one of my design parameters is ZERO budget. My controller is built from parts in my computer junkyard.

Besides, after having spent only 30 bucks on the GS itself, it seems ridiculous to actually spend money on peripherals unless the cost is negligible.

Thanks for your comments.

Offline
Last seen: 6 years 9 months ago
Joined: Dec 20 2003 - 10:38
Posts: 249
I'm not saying you should buy

I'm not saying you should buy a CFFA card especially since you have designed your own card. What I'm saying is Rich already has done this project and he responds to people's email. The firmware is a download and listed in his manual (also available).

I don't have the GS/smartport knowledge that other diehard GS operators do. How well does earlier prodos versions run? Do you run into the same problem with sector 0?

I'm all for building projects based on parts found around the house, much more rewarding when it all works.

Anyways, get ahold of Rich, he will be able to help you out, and he's a good guy.

Vince

CaveNerd's picture
Offline
Last seen: 12 years 6 months ago
Joined: Oct 10 2004 - 17:56
Posts: 17
Some interesting and exciting news turned up

My hack project is un-stuck again... and as with other much more famous inventions, the answer struck as a surprise.

I managed to find some spare time to work on my hard disk project some more - a little more Internet research, and thanks goes to vbriel for encouraging me to check out CFFA again for hints, although that gave me some useful clues, it didn't provide the answer. Here's what happened:

Upon getting an intriguing-looking Google-hit I checked out a Kegs software hack that involved reorganizing GS/OS's boot files so it always boots to P8, where you could "bye" to a modified GS/OS loader stub. I tried partially implementing that hack, and indeed my GS/OS "partition" booted into P8 no problem, but still wouldn't go for the GUI. What that did do for me though was tell me that the problem wasn't with the boot stub as I suspected, but with the PRODOS stub (GS/OS loader).

So I did what my ancient hacker-instinct told me to do. I reconfigured the OS back to normal, then reconfigured the BRAM to coldboot with a scan - something I hadn't done before, since during the debugging phase of the ROMcode I'm loading it from diskette using a static ram patched into the project in place of a PROM. The intention was to boot-trace my way into the problem so I could get an idea of how to solve it.

The intention was to use the "hold 8" option for 6.0.1 and see if that changed the playing field at all. It didn't work - that is, since I couldn't power-up-coldboot the hard drive I had to try to be fast enough with the 8 key to catch the bootstrap and load P8. I wasn't fast enough. What happened instead was GS/OS started booting up no problem!!! It seemed that life is beautiful after all - my homebrew IDE controller indeed boots GS/OS 6.0.1, albeit only as a coldboot. Trouble is, I found that the GS/OS install didn't go well, but I have an idea or two as to why, and it did work well enough to boot up.

So now my TODO list has two new items, both of which may cause some trouble:
1. Figure out how to get it to warmboot (either with PR#7 or C700G). For now the ROM is non-portable until debugging is complete.
2. GS/OS is unstable after install. Seems that write cycles to the IDE aren't as solid as they are under ProDOS, can't get a good install of GS/OS on the HDD, just enough to see it's working. Fonts, icons, data get trashed at random, verified as during copy from 800K to IDE during install.

Item 1 may be the hardest, and I might just put that one off indefinitely, since being a homebrew project, coldbooting every time to get GS/OS going isn't such a bad thing.

Item 2 may be a bigger deal - I suspect the IDE's writeback cache is involved somehow, which means another rev on the ROM to disable it, allowing GS/OS's cache to do all the work. Problem is, my ROM is packed - only 6 bytes free as I recall. That may not be enough - while stuck with won't-boot-at-all status, I was considering modifying the hardware to support 2K ROMspace, but rather than adding that complexity I would rather stick to the 256-byte ROMspace instead. It would be a shame to go with a 2K ROM because I'm only a few bytes short of fitting inside 0.25K.

I've also thought about paging the ROM with another flipflop, either to fit the slot-specific code inside the 256-byte space and rewriting a bootstrap to work it out, or to port the basics of the CFFA's SmartPort to my hardware as a last resort.

It was very exciting though - it worked well enough for me to benchmark it. A 6.0.1 install done with "only" the SuperDrive/HDD script booted from power-on to Finder-ready in under a minute. That includes the Static RAM loader/cold-rebooter running under HyperDOS on a Disk II. If/when the project is stable and complete with a ROM I don't expect performance to improve at all, but still it's pretty impressive for a from-scratch solution.

This is still a pretty nifty project, having these design parameters:
1. Basic LBA-mode ATA drive compatibility.
2. Two physical devices online under ROM driver, 32MB each.
3. Possibly more online logical devices under OS-loaded driver (wishlist item).
4. II+(ProDOS 1.1.1)/IIe(any ProDOS)/IIgs(GS/OS) compatibility, unmodified cross-platform (current ROM is 6502-only code, except for the mode8 opcodes, which non-65C816 procs ignore). non-II+ machines (Rev 0/Integer ROM) may not be supported, since ProDOS won't boot with the Integer ROM. But there is one possibility worh investigating, and I do have the hardware to test it...
5. Wishlist: maybe someday working out 3.3 compatibility somehow...

Log in or register to post comments