• Please review our updated Terms and Rules here

Oregon Trail on an 800K disk, is it possible?

2MG has a header. This is raw ProDOS-order.

When the filesize matters, I use extensions like .200 (Nabu), .400, .800 (Apple), .160, .180, .320, .360, .720, .12, .144, .288 (DOS) for raw disk images.
 
2MG has a header. This is raw ProDOS-order.
usotsuki said:
When the filesize matters, I use extensions like .200 (Nabu), .400, .800 (Apple), .160, .180, .320, .360, .720, .12, .144, .288 (DOS) for raw disk images.
Click to expand...
Why use extensions when the filesize itself is eloquent enough? Unless your "super-smart" contemporary OS hides file sizes from you ;)
 
So, I'm confused here. To review, I tried a couple of the options mentioned (items from archive.org) and they haven't yet led me to a "don't need to actually flip the disk" run.

Note, I have an Apple ][e Platinum, if that matters. I don't know the specific disk controller it has - it has been a while since I popped it open, but it has two 5.25 disk drives (physical ones). To avoid wear and tear on the drives, I've swapped the cabling and now using a FloppyEmu.

I came across AppleCider, which has Tools|Disk Image Converter. I converted the given .800 file to all the top 4 options - the "as-is" file seems to be #3 (.po) which was mentioned already (just consolidating notes here).

But someone said AppleWin could run the .2mg version of this image - and I'm not finding that to be the case for me.

Convert to OPTION1 .DO and OPTION 4 just say "Unable to open."

OPTION #3 does open and boot and runs in the emulator just fine (as mentioned, and same with the .800 file - it's binary the same).

OPTION #2 (Unadorned DOS-order with 2MG header) does make a binary-different .2MG file - and AppleWin says it does mount the image. But on a reboot (in AppleWin), it just some kind of crash that shows CPU registers.

1731660134557.png



Next - this is working only with the "hard disk drive" slot 7. None of the images load in the Floppy Disk Drive (which in the real/physical setup, ya'll are saying those are always and only 140KB disks-- at least as far as since I am using "stock" Apple floppy controller card, as far as I know).


So - there's no way to make this work with the stock 140KB disks right? First there is no physical room on the media, or any format that drive might support. Then second, there is no way to detect when the system has prompted to flip the disk, and interpret that to "automatically flip the disk" ?


So for hard disk option (something I never experienced on early Apple's): is there some Slot7 card I need to seek, with a cabling that might be compatible with the FloppyEmu (i.e. even though called "floppy"Emu, it has a mode to support hard disk images).

I do appreciate the .800 file - I understand now it is a self-booting ProDOS (right?), so now my challenge is how to get it to work with the FloppyEmu. I'll try more tomorrow, out of time to tonight.


1731660776368.png
 
Last edited:
Raw ProDOS-order disk image, 800K, with ProDOS-8 self-booting. Yes, that's correct.
 
Great explanation. I mentioned 2mg files due to the AppleWin Help page referring to 2mg as the standard for ProDOS 800k images. I didn't convert the uploaded file in this thread, only added the suffix. Adding .po didn't work when I tried it in AppleWin.

As for real hardware. The floppy emu site states that a IIe with a Yellowstone controller card will allow the floppyemu to read 800k images. It also has a range of image types.
Capture.PNGCapture1.PNG
 
Note/reminder - I didn't actually do a play-thru yet on this .DO image to make sure that, when asked to "flip disk", all users has to do in press a key and no other action. TBD

and tentatively, a "yellowstone" disk adapter may be hard to get these days.
 
It might actually not be hard to modify to use 2 5.25" drives instead of 1; the filesystem is DOS 3.3 and most of the code is interpreted BASIC.
 
Oh no, the image locked up on me at the Fort where it asks to flip the disk. Bummer, it was a good run so far. Everyone was still alive at least.

When you reach the Fort below after a couple river crossings (and past Chimney Rock), the game generally ask to flip the disk over. The message didn't appear with the .PO being discussed (at least on my running of it with 1.30.19.0), and it just sat at this scene as if the system had locked up.

1731727092406.png


Here was the emulator state. I don't know the Apple system well enough to say if this was stuck in some interrupt or what? I did try pressing a key even tho the message wasn't shown. So, at least for me, that .800 still isn't reaching the desired goal.

1731727117929.png
 
Last edited:
Edited, thanks - did mean .PO (or "option 3" in my earlier screen shot).

A modified build to assume the "flipped disk" is in Drive B sounds good (but maybe a little trickier than it sounds - at the end of the game you need to flip back, iirc? except now I'm not sure where the high score table goes)
 
voidstar78 said:
Edited, thanks - did mean .PO (or "option 3" in my earlier screen shot).

A modified build to assume the "flipped disk" is in Drive B sounds good (but maybe a little trickier than it sounds - at the end of the game you need to flip back, iirc? except now I'm not sure where the high score table goes)
Click to expand...
The easiest option would be to use 2 140k images in floppyemu with the dual disk option if the 800k image doesn't transfer to the second side as you've reported. If the double drive mode is available. IDK how it works..

Floppy Emu Update: WOZ Writes, Dual 5.25 Emulation, and More! | Big Mess o' Wires

www.bigmessowires.com www.bigmessowires.com
Capture2.PNG
 
Well true, the original code at the end would looking for the flipped side back in A, after (ideally) referencing B for the second portion of the game. So maybe no mod would be necessary (at the end of OT).

I did try the dual 5.25 option in FloppyEmu (with original SideA/SideB image) - and configuring/setting it up wasn't too bad, along with designating which side. And I did try a run of OT but it wouldn't read (or attempt to read) from B at this "critical point".

Maybe I can ask if they could do a modified firmware - such that from the disk emulator side (FloppyEmu itself), maybe it can respond to disk access request to automatically cascade from A to B (or vice versa) before failing a request? Something runs in my mind that the HxC drive emulator that I use on the IBM PC does that (which can also emulate two drives in one). [ then again, maybe it was just a behavior difference between DR-DOS instead of MS-DOS; can't recall ]

Actually - can I boot/start original OT from B: ? Then at this "critical point" what if it's hard-coded to look back at A? Can give it a try when I get back to the FloppyEmu equipment. [ don't think it'll work since I have to init the image into A-drive slot, so then I'm not sure how to force booting from B? actually, the FloppyEmu might have had a specific setting option for that ]
 
Last edited:
If somehow you boot DOS 3.3 another way, and then put Oregon Trail in D2, you can run HELLO and it'll work fine afaict.

A possible hint for modifying Oregon Trail to use 2 drives: The relevant code can be found on both sides in the file FLIP.LIB. I don't yet know how to set the disk drive as the MECC driver understands it, though.
 
You must log in or register to reply here.
Back
Top