WinOSI lives!

MK14HAK
Posts: 294
Joined: Wed Mar 16, 2011 1:49 am
Location: New Zealand

Re: WinOSI lives!

Post by MK14HAK » Tue Oct 30, 2018 8:42 pm

Mark wrote:
Fri Oct 19, 2018 5:56 am
WinOSI is getting native HFE file support too!
Mark, any chance of 14 char file name support ??

14CHAR Dir.JPG
14CHAR Dir.JPG (32.23 KiB) Viewed 289 times
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:Archive/Restore Util,HexDOS,FDD Emulator

Mark
Posts: 23
Joined: Tue Sep 16, 2008 6:04 am
Contact:

Re: WinOSI lives!

Post by Mark » Tue Oct 30, 2018 10:16 pm

Hey I didn't know about 14 character filenames. If you can document it I can add it to WinOSI!
Any sample disk images available?

Looks like I have some testing to do...
I'm working on finishing the latest version. There have been a number of changes including a fractional scalable display window, integration of terminal mode window with main emulator window, debugger enhancements, better large font support for windows 8+, printer output capture, HxC HFE file support, loading of OSI & binary data with drag & drop/file open, command-line configuration selections (-c1p -c4pmf etc.) and automatic emulator configuration based on configuration stored in path. Thus if you have C:/OSI/Disks/C1PMF/... or C:/OSI/Disks/C4PMF/... files they will be run with the appropriate configuration when launched from Windows Explorer or command-line. The practical upshot of this is you can double-click a disk or tape icon in a folder and WinOSI will launch it with the appropriate environment.

I'm still chasing down some windows messaging issues and perhaps a GDI memory leak.

MK14HAK
Posts: 294
Joined: Wed Mar 16, 2011 1:49 am
Location: New Zealand

Re: WinOSI lives!

Post by MK14HAK » Tue Oct 30, 2018 10:47 pm

Thanks for the continued WinOSI support Mark. Awesome!

This is how a 14 char directory looks in WinOSI and and an image with Directory only included here.I will post more info on the mod at some stage. Some areas are still a WIP with DOS not reporting free tracks correctly but otherwise load and save are fine and DQ Sec modified ok, but I haven't looked at it for a while.
WinOSI 1.3 Image Contents 14CHAR display.JPG
WinOSI 1.3 Image Contents 14CHAR display.JPG (20.14 KiB) Viewed 287 times
Ill follow up with a few feature suggestions and bugs later.
Mike
Attachments
BlankOSI 14CHAR Dir.65D.zip
(639 Bytes) Downloaded 13 times
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:Archive/Restore Util,HexDOS,FDD Emulator

Mark
Posts: 23
Joined: Tue Sep 16, 2008 6:04 am
Contact:

Re: WinOSI lives!

Post by Mark » Wed Oct 31, 2018 2:08 am

Okay,
The standard OS65D directory format is:
2 sectors (1 & 2) on track 12 (8 for 8") hold the directory information.
Each entry requires 8 bytes. There are a total of 64 entries. The entries are formatted as follows:
0-5 ASCII 6 character filename
6 BCD First track of file
7 BCD Last track of file

The 14 character filename conversion appears to be:
Each entry requires 16 bytes There are a total of (32?) entries (or are sectors 2x larger?)
The entries are formatted as:
0-13 ASCII 14 character filename
14 BCD first track of file
15 BCD last track of file.

How can we differentiate between standard and extended filename directories programmatically? Invalid track ranges? Hi bit set?
Since this is a custom OS change, I'm not sure how the emulator should handle this. I guess blank disk creation could/would be unaffected, its just the viewing of directories in the emulator that needs to be smarter. Hmmmm

MK14HAK
Posts: 294
Joined: Wed Mar 16, 2011 1:49 am
Location: New Zealand

Re: WinOSI lives!

Post by MK14HAK » Wed Oct 31, 2018 2:57 am

Two 256 byte sectors as per OS65D. 16 file names each sector for 32 total.
A compromise that works for me as I'm over 6 byte names for all my own utils I generate. More meaningful names are really helpful.

All WinOSI would need is to display them correctly with associated track numbers.Blank image creation is not affected.The modified DOS handles the filename/track convention for save and load. Maybe its too much work but DOS65 would have the same issue if I recall correctly.

Maybe use ' : ' as the first character for the first directory entry filename as I use this name as a Volume name, to differentiate the directory format.
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:Archive/Restore Util,HexDOS,FDD Emulator

Mark
Posts: 23
Joined: Tue Sep 16, 2008 6:04 am
Contact:

Re: WinOSI lives!

Post by Mark » Wed Oct 31, 2018 7:17 am

My floppy media version of Hexdos4 boots fine. I can load a directory and it displays the filenames and tracks correctly. Problem is I cannot load files by "filename" . Result- ? DF error
All files load by track OK. Tried different step rates @ $04ED - no joy. Save "filename" return - drive starts, system hangs until a key press,then ? DF error. A similar sequence as the load.

So I reverted to WinOSI for testing...

Using an image created the same way with same BASIC ROM and Cegmon configuration, the disk image boots and loads files by "filename" in the earlier version of WinOSI no problem but again I get a different error - DT error but only in WinOSI v1.5.2 ??

Does anyone have a problem with WinOSI 1.5.2 and HexDOS4 filename loads ? DT error :?:

Edit: Using image from bxDanny: HEXASM does not load - ?DT error. But creating and loading a new file does work for a new file (using WinOSI 1.5.2) ???
HEXASM loads OK in earlier WinOSI using the filename method though. ??

Mike
Well I figured out this bug.

Once booted, Hexdos reads from the disk ACIA while waiting for the index hole to pass, causing the emulated read pointer to increment. On real hardware this wouldn't affect the data, but in WinOSI several bytes were read and ignored so Hexdos couldn't find the expected start of track, generating a DF error. I think Hexdos does this to clear any garbage streamed in before the index hole has passed, not a bad idea.

OS65D and OS65U don't read the ACIA until after the index hole passes so it didn't affect them. WinOSI will now correctly not increment the track data pointer until after the emulated disk index signal has passed.
I think this problem didn't exist in old versions because the simulated disk drive was a lot simpler. It became more complex in order to support OS65U, which does things like write to the disk controller without drives being enabled in order to calculated CPU speed. Clever! Many changes were made trying to get OS65U to work, but in the end it was a combination of garbage on the disk images and and ACIA format change/reset in the middle of track data.

I the process of looking at this, I now see how Hexdos stores directory information. Anyone have a complete disk image to look at? I'd love to add it to the WinOSI directory preview.

I need to track down DOS/65 to see what it does...

-Mark

MK14HAK
Posts: 294
Joined: Wed Mar 16, 2011 1:49 am
Location: New Zealand

Re: WinOSI lives!

Post by MK14HAK » Wed Oct 31, 2018 11:02 pm

Nice fix.
The DOS BPSECT routine at $299B is called by the DI directory command at $29F3. This routine also counts bytes after the index hole. From your explanation of this fix, I think you may also solved another bug whereby the DI command hangs in WinOS 1.5.2 ??
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:Archive/Restore Util,HexDOS,FDD Emulator

Klyball
Posts: 175
Joined: Tue Dec 09, 2014 12:53 am

Re: WinOSI lives!

Post by Klyball » Sun Nov 04, 2018 6:13 am

Is there a way to get a lod file in the c3 emulation or get hex in memory , I can't seem to figure it out?

THX
Replica 600 Rev D:8K,CEGMON
Replica 610 Rev B: 24k,MPI B-51 with Custom Data separator D-13
510 on the bench/replica 582 backplane/replica 470a /replica 555/original 570B/2 x Shugart 851
Ongoing : 630 ,620 ,510,542c,custom 590,SA1200,592,594,596,598

Mark
Posts: 23
Joined: Tue Sep 16, 2008 6:04 am
Contact:

Re: WinOSI lives!

Post by Mark » Tue Nov 06, 2018 6:59 am

With WinOSI v1.5 you can load a ".lod" file outside of the emulated OSI from the main WinOSI emulator window File/Load OSI File... or press F2. The final execute address is shown in a message box (if there are any). It also accept MOS checksum loader format. It places data in memory directly.

BTW, to load a file with a real C3, use the command-line OSIALOD utility to create an OSI 65A compatible loadable file. Start the C3, enter 'M'onitor and send the 65A file using a terminal program RAW ACSII send.
Unfortunately the mini terminal in WinOSI V1.5 doesn't have a send data/capture data so you can't send data in the emulator this way. (yet)

Note: You can use OSIALod to create 65V ".lod" files too as well as MOS Checksum format files & a binary version I used to use to save space QSave ".qsv"

-Mark

Klyball
Posts: 175
Joined: Tue Dec 09, 2014 12:53 am

Re: WinOSI lives!

Post by Klyball » Tue Nov 06, 2018 7:08 pm

Thanks Mark,

Still can't get the .lod files in but the chk files work,
Thanks for your help
Replica 600 Rev D:8K,CEGMON
Replica 610 Rev B: 24k,MPI B-51 with Custom Data separator D-13
510 on the bench/replica 582 backplane/replica 470a /replica 555/original 570B/2 x Shugart 851
Ongoing : 630 ,620 ,510,542c,custom 590,SA1200,592,594,596,598

Post Reply