Is there a stand alone high speed SIO driver for the 800?

[+Larry]

"What-if"  There are a number of them for XL/XE, but are there any for the 800?  There are several imbedded in specific dos types, including the Warp Speed drivers for Dos 2.0 and Dos XL, and the Synchromesh drivers for INDUS.  And US drivers for Sparta.  But how about an 800 driver that will work with most any Dos?  Could Hias' drivers be made to work with the 800?   Perhaps it could use Axlon memory?  Maybe it would slow it down, but still be faster than 1X?  

[ivop]

Hiasoft's website says:

 

126kBit work both with new XL/XE OS and old 400/800 OS

 

That's version 1.30 from 2010-11-25

 

[HiassofT]

If you've got RAM at eg 48-52k you could put the driver there (either assemble it manually or use the highspeed driver code at $CC00-CFFF in the highspeed patched XL OS) - in addition to that you need to patch the software (eg DOS or application) to use the highspeed code instead of $E459.

so long,

Hias

[ivop]

Oh, I was thinking that "and old 400/800 OS" would mean you could also create a 10kB ROM with your high speed SIO code. So that's not possible I assume, as in the XL ROM it resides in the international character set space. Perhaps a 400/800 OS ROM version could be made by replacing the C : handler? Or get an Incognito

[+Larry]

3 minutes ago, ivop said:

Oh, I was thinking that "and old 400/800 OS" would mean you could also create a 10kB ROM with your high speed SIO code. So that's not possible I assume, as in the XL ROM it resides in the international character set space. Perhaps a 400/800 OS ROM version could be made by replacing the C : handler? Or get an Incognito

I've certainly thought about an Incognito.  But I have several XL/XE computers, so I want to keep my 800 as an 800.  Hias advice about putting it at $C000 seems the easiest to do.  Now I need a board with 52K.  I'd love it if the tf_hh 400 board can be modified to work in the 800.  I really like the idea of being able to switch OS by moving a jumper.  Probably will have to do some minor soldering if it pans out, but I'll get it done.  In the meantime, I'll probably use WARP Dos 2.0 when needed.

[TGB1718]

I wrote a high speed SIO driver bitd, I know it worked with early SpartaDOS , OS/A+ and SmartDOS but never tried

on the older DOS's as I had moved to DD disks and no longer used single/enhanced, although if I was using a single/enhanced

old disk while using SmartDOS, I know the sectors were read in at high speed.

 

I think the code was on some old disks that I can no longer read, but if I do find it, will post it here for interest sake

 

[+Larry]

That would be great, if you can find it.  Any idea how you did it?

[TGB1718]

15 hours ago, Larry said:

That would be great, if you can find it.  Any idea how you did it?

Been round the goldfish bowl a few times since I did it, maybe if I find the code it will jog my memory 🤓

[Rybags]

Biggest problem - disk and SIO jump vectors are fixed in ROM with no RAM based pointers.

 

With a stock OS the only way to patch it in would be to modify the Dos itself.

That would mean doing every individual Dos out there.  Then you have the memory issue - the SIO code has to sit somewhere and the likely place would be after the Dos code then modify the Dos to put it's buffers further onward.  Then the issue of Dos 2.x and DUP overwriting a bigger Dos.

On a 52K system it becomes easier but how many of those out there to justify the effort?

 

[TGB1718]

8 hours ago, Rybags said:

Biggest problem - disk and SIO jump vectors are fixed in ROM with no RAM based pointers.

 

I know my Hi-Speed SIO driver was for 64K+ machines only, it copied OS to RAM, changed the SIO

vector and wrote the Hi-Speed code into the OS area, overwriting some ROM code, can't remember what it 

overwrote at the moment, but it worked and I used it with BASIC,MAC/65 and BUG/65 with no problems

[Rybags]

I remember being able to force higher speed tape output by using an immediate VBlank routine which is fairly cheap on memory (maybe a couple of dozen bytes)

 

But I'm not sure if that method could work on disk - aren't the command frames sent at normal speed?  I guess there's probably a Ram based flag to tell us command frame is in progress which might help.

 

[_The Doctor__]

intercept wedge possible?

 

[Rybags]

I don't think so.

In theory you could override vectors for the D device but it's too high-level.  You have CIO then the actual device driver within Dos which in itself does some sort of dodgy stuff for burst mode then it calls either the disk or SIO routine $E453 or $E459.

Stock OS has no provision to change the default bitrate.

Each different Dos would require very different patching to embed high-speed SIO.

Like any mod for 6502 OS/firmware/driver the problem becomes memory management.  Whereever you put the needed extra code it's going to be stomping on something.

[+Larry]

I was using Warp Dos XL recently.  V2.35 (with an upgraded 600 XL), so I need to look at the code.  The Happy drive kicks into Warp Speed mode very quickly -- certainly on the first disk track, maybe as soon as the boot sectors.  Not stand alone, but might provide some ideas.  Does anyone have a *well-commented* disassembly of the standard Dos 2.0 or 2.5 boot sectors?  I think one was posted recently, but I can't remember what thread it was for. Maybe posted by @ivop?

 

Edit:  2.35 is the Synchromesh version for Indus.  A Happy Drive will no respond to this code.

[Rybags]

You could have the boot sector + some turbo SIO code in under 1/2 K.  Fairly sure the early boot code in most Doses will look for the Dos.sys file and continue to load which would add some extra overhead.

 

Inside Atari Dos has source + a chapter describing the boot process.  Dos 2.5 would be almost identical for that process I'd say.

[ivop]

5 hours ago, Larry said:

I was using Warp Dos XL recently.  V2.35 (with an upgraded 600 XL), so I need to look at the code.  The Happy drive kicks into Warp Speed mode very quickly -- certainly on the first disk track, maybe as soon as the boot sectors.  Not stand alone, but might provide some ideas.  Does anyone have a *well-commented* disassembly of the standard Dos 2.0 or 2.5 boot sectors?  I think one was posted recently, but I can't remember what thread it was for. Maybe posted by @ivop?

Perhaps you were thinking of this: https://github.com/ivop/romdos/blob/main/bootcode/bootcode.s ?

 

It's the bootsector of the ROMDOS boot disk.

[+Larry]

Thanks, pretty sure that's the one.

[+bob1200xl]

Doesn't the SIO code in the OS control the process? DOS just calls for a data transfer, OS has to execute it. My high speed code runs under DOS2.0 just fine. It just requires a patched OS ROM.

 

Bob

 

[reifsnyderb]

With an XL, can't you move the ROM to RAM then patch it in RAM?  The biggest problem I see, though, is software that also wants to use the RAM "under" the ROM.

[Rybags]

You could.  But you don't know what OS version is there.

Potentially 5 or more stock XL/XE ones.  And an infinite possibility of custom ones.

But it's as much or more intrusive as lower Ram based SIO code.

[+Larry]

On 2/2/2023 at 6:42 PM, bob1200xl said:

Doesn't the SIO code in the OS control the process? DOS just calls for a data transfer, OS has to execute it. My high speed code runs under DOS2.0 just fine. It just requires a patched OS ROM.

 

Bob

 

Hi Bob-

Patched for an 800?  These Dos-specific versions like Warp Speed Dos 2.0 and W.S. Dos XL worked with stock 800's and required Happy Drives (or something that imitated a Happy Drive).  I just happened to test Dos XL 2.35 with a 600 XL.  The XL series was such a game-changer in so many ways!

 

That brings up another question -- were there high speed drivers for other dos versions that did not need an XL or XE?  Maybe disk-based Sparta?  I know little about SDX, but I don't think that it worked with 400/800. (?)  I suspect that my motivation for starting this thread last August was to find a high speed driver that worked with MyDos + an 800.

 

Edit: I just ran across another version of Warp Speed Dos XL -- this one is labeled V2.42.  I'm not sure what the differences are versus V2.35.  I'm pretty sure that the one I originally got from Happy was 2.35.  The Happy docs say that the driver for Dos 2.0 got smaller with Rev 7, so this one may have also.

 

Edit2: 2.42 is the Happy Warp Dos XL (not 2.35).

[+David_P]

SDX will run on a 400/800; but you need either expanded RAM or a very stripped down CONFIG, since there's no RAM hiding under the OS ROM.

[BillC]

2 hours ago, David_P said:

SDX will run on a 400/800; but you need either expanded RAM or a very stripped down CONFIG, since there's no RAM hiding under the OS ROM.

The original ICD/FTe SDX cartridges are compatible with the 400/800 when configured correctly, but some early versions of SDX 4.x aren't, this was resolved in v.4.46 and later IIRC

[flashjazzcat]

Install an Incognito. Problem solved.

[+Stephen]

46 minutes ago, flashjazzcat said:

Install an Incognito. Problem solved.

Bang in a VBXE too, so you can properly enjoy SDX as well as some other goodies!