How to xfer software from PC to an 8-bit platform?

[6BQ5]

There seems to be a lot of 8-bit software available for download. How do I transfer it to an 8-bit machine? I imagine there must be a USB<->SIO cable available. Do I just mount the Atari drive in Windows under it's own drive letter and copy the software over? That seems too easy. Personally, I would love to avoid magnetic media and have some sort of small solid state storage media, like a SD card or USB flash drive.

 

Sorry for the total newbie question here. I gotta start somewhere and this looked like a safe forum to start.

 

I don't have an 8-bit machine yet but I am hoping to buy one soon. It's probably going to be a 130XE. It was the 8-bit machine I lusted for when I wasn't drooling over the 520 ST.

[budburns]

There are many devices out there to accomplish this. One of the original (and still the best) IMHO can be found here:

 

https://atarimax.com/sio2pc/documentation/

[xrbrevin]

I use aspeqt software and SIO2PC by lotharek - daisy-chained from a real 1050 drive

set your disk drive to drive 2 and put a blank in it, load a sector copier from the PC as drive 1 onto your atari (e.g. mycopyr or copy2000)

'eject' the emulated drive 1 and 'insert' an ATR file of your choice

start the sector copier and it will create a real wolrd bootable atari disk

[+Nezgar]

There's a pretty comprehensive list curated on the first post of this thread:

 

http://atariage.com/forums/topic/176545-topic-for-newbies/

 

But I also +1 the SIO2PC-USB by Lotharek as your first entry perepheral.

[SS]

I like the SIO2SD because it doesn't leave you tethered to a PC.

https://lotharek.pl/productdetail.php?id=60

 

There also also the UNO or Ultimate Cartridges for ROM/CAR/XEX format files.

https://www.thebrewingacademy.com/

 

Definitely read the thread that Nezgar linked too. There is tons of valuable information located there.

Edited December 14, 2018 by SS

[Gavin1968]

Sounds like you need an SDrive-MAX to me

I know where you can get a really good one.

 

Edited December 14, 2018 by Gavin1968

[SS]

Actually if you aren't interested in reading/writing between your device and real floppy disks, one of Gavin's SDRIVE-MAXs is a good idea. Easy to drag and drop files to the micro-SD card and then run them on the Atari via the SDRIVE-MAX. It's a bit easier to just plug-n-play than the SIO2SD or SIO2PC are too.

 

.

Edited December 14, 2018 by SS

[Kyle22]

I have the SDrive Max, it is nice, but for general purpose transfers, I use this setup:

 

Windows (XP32) laptop running RespeQt 4.2.1

SIO2PCUSB cable that cost $9.00 from eBay and I had to solder my own SIO plug on the end of it. Just make SURE that it uses a REAL FTDI chip.

SpartaDOS-X with PCLINK.SYS driver loaded.

 

It's as simple as:

 

Browse for your file in Web Browser (I use FireFox).

Right Click -> Save As->(browse to your My Documents\Atari folder)->Click save.

At the Atari, type (assuming you have set up the PCL: drive ad D:):

 

DIR PCLD: (Shows directory)

COPY PCLD:FILENAME.EXT D1: (or other drive)

or just run it. Let's say it was Donkey Kong, and it's name (as downloaded) was Donkey.xex

type:

X PCLD:DONKEY.XEX

 

It runs.

 

Very simple.

[Mechanicjay]

ptsh.

I telnet into my linux box with BOBTERM and xmodem stuff over

Or just load up an ATR via Side2. But what the folks above say is the overall better solution.

 

[+DrVenkman]

There are so many good solutions, pretty much all of them listed above. My personal option 75% of the time is using an ATR or ATRs mounted in disk slots in RespeQt; the rest of the time I load disk images from the microSD card in my SDrive-MAX device. If I'm using one of my Ataris with an Ultimate 1MB board, I'll sometimes mount ATR images contained on the CF card in my SIDE2 cartridge or the XEL-CF card adapter on my 1088XEL. The downside to this last approach is it requires use of the PBI BIOS option in the U1MB options, which changes the free RAM available and can interfere with running some programs.

 

For XEX files, there are even more options: loading from my UNO Cart, loading from my SIDE2 cart, loading via RespeQt or SDrive-MAX, or via SpartaDOS X straight off of CF card hard disk partitions.

[+Larry]

If you have a Windows PC handy (and a small, even really slow laptop is fine), then some form of SIO2PC is a really nice way to go. Unlike Atari devices like S-Drive or SIO2SD, you have the ease of Windows GUI to make you tasks easier and more intuitive. I've just never cared for the "push the buttons" method of file selection/manipulation the SD card devices use. (Although there is a file for the SIO2SD (and maybe the S-Drive) that allows you to use the Atari screen for file selection.) I must admit, I'm intrigued by the S-Drive Max since it gives you better screen info than older versions. I'm a 98% APE Windows USB user, and the other 2% is usually RespeQt. RespeQt also supports Linux, I believe.

 

These aren't all the methods available, but they are the most common for moving ATR images from/to a PC. At any rate, with the Atari, you have plenty of ways (and software) to choose from.

 

Here are some links to check, if interested: (some are duplicates from above)

 

http://atariage.com/forums/topic/275629-sdrive-max-atx-support/

https://lotharek.pl/productdetail.php?id=60

https://www.atarimax.com/

http://atariage.com/forums/forum/184-respeqt-sio2pc-software/

 

Good luck!

-Larry

[flashjazzcat]

If I'm using one of my Ataris with an Ultimate 1MB board, I'll sometimes mount ATR images contained on the CF card in my SIDE2 cartridge or the XEL-CF card adapter on my 1088XEL. The downside to this last approach is it requires use of the PBI BIOS option in the U1MB options, which changes the free RAM available and can interfere with running some programs.

In what way does enabling the U1MB PBI BIOS change the amount of free RAM available to the system?

[+DrVenkman]

In what way does enabling the U1MB PBI BIOS change the amount of free RAM available to the system?

 

It doesn't? Hmm. Well, you'd know better than I. I *do* know that enabling the PBI BIOS can create compatibility issues with some titles, which is why I put in the caveat.

[flashjazzcat]

Outside of RAM under the hardware registers (memory which is normally inaccessible anyway) and ROM under the math pack, the PBI BIOS uses nothing but a dozen or so ZP locations at $3x which are reserved (by Atari, at least) for handler use. The BIOS does not depend on any of these locations maintaining their values between SIO calls, but will obviously stomp on any applications or drivers unwise enough to use them (fortunately there are very few of them; a word in the same PZ area used by disk-based SpartaDOS is deliberately avoided by the BIOS). Other than that, there should be little scope for compatibility problems. The forthcoming firmware update fixes a loader dependency on a long word at $3x maintaining its value between segment loads, fixing a loader compatibility issue with one title (PANG), but no such issue exists with the same title loaded via a PBI mounted ATR or hard disk partition.

 

Naturally there are some programs and disk operating systems which simply have a problem running from PBI hard disk partitions (or PBI mounted ATRs) in general and regardless of the PBI device in use (such as a loader which insists on providing its own IO drivers, for example), but that's a generic issue which is normally solved by launching the software from a serial device.

[Faicuai]

Outside of RAM under the hardware registers (memory which is normally inaccessible anyway) and ROM under the math pack, the PBI BIOS uses nothing but a dozen or so ZP locations at $3x which are reserved (by Atari, at least) for handler use. The BIOS does not depend on any of these locations maintaining their values between SIO calls, but will obviously stomp on any applications or drivers unwise enough to use them (fortunately there are very few of them; a word in the same PZ area used by disk-based SpartaDOS is deliberately avoided by the BIOS). Other than that, there should be little scope for compatibility problems. The forthcoming firmware update fixes a loader dependency on a long word at $3x maintaining its value between segment loads, fixing a loader compatibility issue with one title (PANG), but no such issue exists with the same title loaded via a PBI mounted ATR or hard disk partition.

 

Naturally there are some programs and disk operating systems which simply have a problem running from PBI hard disk partitions (or PBI mounted ATRs) in general and regardless of the PBI device in use (such as a loader which insists on providing its own IO drivers, for example), but that's a generic issue which is normally solved by launching the software from a serial device.

 

Well, here's the deal:

1. I am running OS posted here: http://atariage.com/forums/topic/285568-a800-i-incognito-bringing-back-the-right-cart-port/?p=4168130
2. I can now see OS-posted traces of Cart A and/or B signatures, posted during execution of $C3C4 and $CBB0 (heart of the extensions).
3. Now the interesting part:
   • I first load EYE2.COM in SIO logical drive #1, on Nuxx Drive.
   • DISABLING SDX, DISABLING BASIC and ENABLING PBI Bios (including Hard Drive = ON), and then booting by pressing "B" and then "D", and then "1", takes me to Page 0, immediately, and what do I find?:
     • $00 posted-code on $06 (which under new OS, it means VALID cart on $A000-$BFFF).
     • $FF/$80 codes on $3D and $3F (means CartB absent, not detected, which means above cart was a LEFT-8K Cart !)
     • $05 Exec. Flag posted on $3F (which means there was a cart with a [iNIT + Disk Boot] flag set on $BFFD.
     • Now, the funny part:
       • Go to $6A and I find: $C0.
       • Go to $02E4 and I find $C0.
       • That means TOP of RAM is set ABOVE $A000-$BFFF cart space (!!!) In other words, full base ram available under XL OS ==> NO Cart !?
       • Lo-and-behold, I jump to $BFFA with EYE2 and all I find there are ZEROs that I can write over at will (== active RAM!)
       • yet a Cart was originally detected by OS AND INITIALIZED because of $05 flag (!!!)
       • Self disappearing? It smells to me, all over the place, like Basic was there FIRST, and got banked out right before OS DBA (disk boot attempt), and RAM vectors got adjusted, as well as Gr.0 screen buffer.

Oddly enough, the story does not end there:

• By repeating the very first two steps, above, with exact same BIOS config, but briefly HOLDING "OPTION" key, while BIOS pre-boot screen transitions to dark, releasing RIGHT before Gr.0 screen appears before starting SIO Drive1 boot, I get:
  • $80 posted-code on $06 (which under new OS, it means CartA ABSENT / not-detected in $A000-$BFFF).
  • $FF/$80 codes on $3D and $3F (means CartB ABSENT / not-detected)
  • $00 Exec. Flag posted on $3F (which is consistent to Cart A&B absent in space $8000 - $BFFF).
  • Final result:
    • Go to $6A and I find: $C0.
    • Go to $02E4 and I find $C0.
  • THIS is what I would expect in BOTH scenarios (!)

I know this is not an Egyptian discovery of any kind, but... unless I am missing something at the OS level that I have not yet traced (which I really doubt), it seems to me that PBI Bios is involved in managing RAM during OS boot-stage...

I can only wonder...

Edited December 15, 2018 by Faicuai

[flashjazzcat]

The PBI BIOS is responsible for disabling internal BASIC when necessary and the fact it does so does not contradict any of the facts I presented in my prior post. You have BASIC disabled, hence the traces of intervention. No provision is made for right carts, so if there's something you need changed in the Incognito build, let me know. I have no right hand carts and thus no way of testing.

 

It's not clear from your description which cart slots are actually populated when all this is happening.

 

If BASIC is left enabled and the loader has not directed the PBI BIOS to disable BASIC on a one-off basis, you should see no interference in the state of internal BASIC (which is to say, none of the above is a result of simply enabling the PBI BIOS).

 

The same goes for boot drive redirection, if one wishes to enable necessary features in order to observe them interfering with the normal boot process. Said boot redirection can be turned right off and is not necessary for PBI BIOS operation.

 

Of course if anything needs fixing, now would be an opportune time to tackle it, and reports are most welcome. I can barely generate any interest at all in beta testing, so it's heartening to know someone is paying attention.

Edited December 15, 2018 by flashjazzcat

[Faicuai]

The PBI BIOS is responsible for disabling internal BASIC when necessary and the fact it does so does not contradict any of the facts I presented in my prior post. You have BASIC disabled, hence the traces of intervention. No provision is made for right carts, so if there's something you need changed in the Incognito build, let me know. I have no right hand carts and thus no way of testing.

 

It's not clear from your description which cart slots are actually populated when all this is happening.

 

If BASIC is left enabled and the loader has not directed the PBI BIOS to disable BASIC on a one-off basis, you should see no interference in the state of internal BASIC (which is to say, none of the above is a result of simply enabling the PBI BIOS).

 

Of course if anything needs fixing, now would be an opportune time to tackle it, and reports are most welcome. I can barely generate any interest at all in beta testing, so it's heartening to know someone is paying attention.

 

Quality of attention may be more important that volume of it... :-)

 

So in the essence of your time:

 

1. NO carts plugged when running the above scenarios (NONE physically connected, on neither CartA nor CartB slots).

2. BASIC was ALWAYS set to DISABLE (option).

3. I NEVER went to the "Loader" (if you refer to SIDE). All I did was press the "B" key, together with the steps described above (to boot ATR in SIO drive #1)

4. PRESSING the OPTION key at the moment described above, clearly made a difference in the $A000-$BFFF memory space, which suggests a ROM was there during OS cart-boot manager stage, and then it disappeared (!)

 

I have not observed any adverse effect, other than two interesting things (not sure if related, though):

• If I plug a RIGHT cart, and press "L" for SIDE loader (with PBI off, blank SIO drive), the screen goes to Gr.0, attempts disk-boot (OS BDA), and blacks out (prob. CPU crash).
• With the same RIGHT car plugged, I enable PBI BIOS and press "L" (with OPTION momentarily held, blank SIO drive), OS attempts a disk-boot (due to OS improvements and hardening).
• Upon further tracing, there is a $A000-$BFFF "cart" that appears on that space (next to my RIGHT cart), with CARTCS vector of $A3C6 and CARTAD vector of $BFF4 and Exec. flag = $04. This IS NOT Basic's cart signature. It is something else. When I follow these in correct order, they lead to a dead-end (blank screen). Not sure if it is trying to run code on $8000-$9FFF space, or where it is going though (seem SIDE related, but it is crashing somewhere).
• If I try to boot the very useful MyCopier 2.1 in ANY XL-OS or OS-b mode (and from .EXE or .ATR SIDE loader), it will stop with "REMOVE CART" even if I disable BASIC on BIOS or even press OPTION during boot... ONLY way for that thing to work is to boot MyCopier directly from SIO in OS-b mode, and then it works... Not sure why, though, but it maybe related to my findings...

No problem that I can't overcome at this point, but I think it is worth the time to take a look at this, for future improvements. Count me in for anything you may need on this front.

Edited December 15, 2018 by Faicuai

[flashjazzcat]

It wasn't immediately apparent whether this was a bug report or not, but if there's no observable issue with a stock OS and normal cart usage, that's good news and not unexpected. Provision was made in July's release for 16K carts, but no right cart usage was ever envisaged and is thus not inherently supported. The 800 OS supports right carts, but does not support the PBI BIOS. Of course I have absolutely no objections to making any reasonable changes which allow a custom OS which boots right carts to coexist with PBI suppression of internal BASIC (a ROM which the stock 800 also lacks, of course).

 

Note that suppression of BASIC is a convenience feature which has been present since the very first U1MB/Incognito PBI BIOS and latterly expanded (at user request) to allow persistent suppression of BASIC even if only the PBI HSIO driver is in use. It's only possible to manage BASIC at strategic stages of the boot however, and - importantly - never at the same point the OS does so. If adverse effects are observed which are not bugs (as they seem not to be), then the simplest solution may be to turn the feature off.

 

As for MYCOPIER: please send me a copy and I will test it.

[Faicuai]

It wasn't immediately apparent whether this was a bug report or not, but if there's no observable issue with a stock OS and normal cart usage, that's good news and not unexpected. Provision was made in July's release for 16K carts, but no right cart usage was ever envisaged and is thus not inherently supported. The 800 OS supports right carts, but does not support the PBI BIOS. Of course I have absolutely no objections to making any reasonable changes which allow a custom OS which boots right carts to coexist with PBI suppression of internal BASIC (a ROM which the stock 800 also lacks, of course).

 

Note that suppression of BASIC is a convenience feature which has been present since the very first U1MB/Incognito PBI BIOS and latterly expanded (at user request) to allow persistent suppression of BASIC even if only the PBI HSIO driver is in use. It's only possible to manage BASIC at strategic stages of the boot however, and - importantly - never at the same point the OS does so. If adverse effects are observed which are not bugs (as they seem not to be), then the simplest solution may be to turn the feature off.

 

As for MYCOPIER: please send me a copy and I will test it.

 

Thanks!

 

1. Attached is executable for your review... This would be GREAT if it could be booted from Incognito's SIDE loader, directly.
   1. Sector_COPIERS.ATR
   2. Try to boot with BIOS's PBI=on, going to Loader "L', and attaching .ATR.
   3. When menu appears. select "US Doubler". See what happens.
   4. I have the .XEX but I can't upload it directly, here.
2. What I really would like to know is:
   1. WHY can't I launch the SIDE Loader with a cart plugged into $8000-$9FFF space?
   2. What memory-space does the "L" command requires? Does it launch something into $8000-$BFFF, entire?
   3. That would be more than enough...

Edited December 16, 2018 by Faicuai

[flashjazzcat]

Attached is executable for your review... This would be GREAT if it could be booted from Incognito's SIDE loader, directly.

Thanks. Everything works nicely on an U1MB machine, but unfortunately MYCOPIER.COM relies on TRIG3 reading 0 when no external cartridge is present, which does not appear to be the case on an Incognito 800. I get the exact same 'Remove Cartridge' error if I select option 'F' after booting the ATR via SIO2PC with SDX disabled, BASIC enabled or Disabled, Option key pressed or not. The application could be patched quite easily to work, however.

 

• What I really would like to know is:
  • WHY can't I launch the SIDE Loader with a cart plugged into $8000-$9FFF space?
  • What memory-space does the "L" command requires? Does it launch something into $8000-$BFFF, entire?
  • That would be more than enough...

• Because of the way Candle implemented the Incognito loader ROM. On the Incognito, the loader is managed as an external 16K (two 8K banks at $A000) cartridge entirely independent of the SDX ROM. On the U1MB, the loader is essentially just another pair of SDX ROM banks, and this allows the loader to obscure external cart ROMs entirely (and thereby use RAM occupied by a 16K cart of a 'right' 8K cart), since SDX is able to manage not only its own ROM state, but also whether the external cartridge appears on the bus. But on the Incognito, the SDX ROM banking system is entirely deactivated when the loader is running, so we have no means of managing external cart ROMs.

   

  One potential workaround on the Incognito would be to move all the code and data the loader normally places in RAM at $8000-$9FFF to $2000-$3FFF and then place all the buffers higher in RAM such that buffer space would simply be truncated if the cart space at $8000-$9FFF were found to be occupied. But it represents a significant change and since 16K carts already work perfectly well with the loader on U1MB systems, I think it's of fairly niche interest.

• As mentioned: the loader uses RAM at $8000-$BFFF. Indeed, it uses ZP and pretty much all RAM from $400 to $BFFF. This presents no issues at all in normal circumstances, and on U1MB systems, the loader can even coexist perfectly well with external cartridges (both 8K and 16K; one can plug in the AtariWriter cart, for example, boot the loader, mount the DOS 2.5 ATR, and boot from that ATR via the loader straight into the AtariWriter cart). The Incognito, however, works differently to U1MB in several small but important ways, which is why some U1MB niceties (reset protection of the FMS under XEX files launched directly from the loader, exit to the loader via DOSVEC from apps launched from the loader) do not work on the Incognito platform. I have no means of addressing these inconsistencies and indeed I doubt Candle would be interested in changing things. We already have the PBI RAM write-through bug which I had to code around on the Incognito. Nothing is life is perfect, but we have to work with what we've got.

• Not sure how to respond.

Edited December 16, 2018 by flashjazzcat

[Faicuai]

Jon:

 

A BIG thanks for your detailed response. Trying to make this usable as well for the rest of the audience:

 

1. I could modify MYCOPIER, as it is probably *THE* overall best utility for handling high-speed, non-protected .ATR data from/to PC and Atari, via SIO. It does almost EVERYTHING automatically, handlig densities like a virtuoso, has its own high-speed code thus running on even OSb, recognizes multiple sources of RAM, handles D1-D4 without problems, and behaves well with Atari XL OS. If it is not TRIG3, which one to check? TRIG2? PORTB? What register and/or value?

 

2. Incognito HAS the ability to launch Loader (as a workaround), even with $A000-$BFFF or $8000-$BFFF space linked to an existing cart. All you have to do is, with cart already plugged on LEFT or RIGHT slot, ENABLE SDX option on BIOS, press "L" (entire 16K $8000-$BFFF is mapped out immediately), SIDE loader appears on screen, select .ATR image to be mounted, once ready, exit back to BIOS main screen, DISABLE SDX, and then "B", with "D" selecting mounted drive, and voila! 8K or 16K cart boots from mounted drive if $9FFD or $BFFD flag bit-0 is set to 1. With the upgraded OS, either a LEFT and/or RIGHT cart will be both booted, properly, or even JUST the RIGHT-cart, provided that you keep OPTION pressed.

 

3. What seems impossible is to switch in and out of the bus the $8000-$9FFF space independently, at the OS via PORTB. But at the moment, I don't see that criticall important, though. I don't even think the A8 was designed for it, either.

 

4. Exiting back to the Loader via DOSVEC from loader-launched EXECs would be WONDERFUL to enjoy Gunstar's Rasta-collection !!! :-)))

 

5. I think you have already done wonders already, and Incognito is just working better than we could ever think it could, thanks to your work. I could, by the way, keep Basic DISABLED directly at the OS level (using OS OWN code), if you could write in page ZERO a specific / literal byte-value, when BIOS "enable basic" is selected (no need to change ANYTHING on your code, in any way, as long as pressing "B" and initiate booting DOES NOT clear that location in Page-0). This would also be compatible with any other OS, either, and extremely easy to implement (but with absolute control of Basic).

 

Cheers!

Edited December 16, 2018 by Faicuai

[flashjazzcat]

If it is not TRIG3, which one to check? TRIG2? PORTB? What register and/or value?

Not entirely sure. GINTLK is going to simply shadow whatever is in TRIG3, so the most sensible option is probably testing that RAMTOP = $C0.

 

What seems impossible is to switch in and out of the bus the $8000-$9FFF space independently, from the OS via PORTB. But at the moment, I don't see that criticall important, though. I don't even think the A8 was designed for it, either.

No, and I think this is entirely outside of the scope of what can be accomplished via BIOS updates.

 

Exiting back to the Loader via DOSVEC from loader-launched EXECs would be WONDERFUL to enjoy Gunstar's Rasta-collection

Yes: and as mentioned, it works beautifully on U1MB machines. I suspect (from experimentation), though, that the Incognito loader - once suppressed - cannot be re-enabled until a system reset has occured (i.e. after the BIOS setup menu has been re-entered and the loader launched from there in the usual manner).

 

I think you have already done wonders already, and Incognito is just working better than we could ever think it could, thanks to your work. I could, by the way, keep Basic DISABLED directly at the OS level (using OS OWN code), if you could write in page ZERO a specific / literal byte-value, when BIOS "enable basic" is selected (no need to change ANYTHING on your code, in any way, as long as pressing "B" and initiate booting DOES NOT clear that location in Page-0). This would also be compatible with any other OS, either, and extremely easy to implement (but with absolute control of Basic).

The BIOS doesn't mess with any ZP locations at all aside from the same ten bytes at $3x as used by the PBI BIOS. Specifically:

 

$30-35

$38-3B

 

If your OS customisations avoid these locations, they will survive a warm reset. Leaving flags for the OS to act upon (if that's the idea) is a little more difficult, since no assumptions are made about how the OS handles anything (aside from the assumption that a couple of interrupt vectors are reinitialised on reset, since the BIOS maintains and observes the primary NMI and IRQ vectors so that Turbo Freezer can work when entered directly from the BIOS menu).

 

A complete copy of the current Incognito configuration (as stored in the DS1305's NVRAM) is stored at $D100, but the OS could only access this RAM by manipulating $D1FF and only if the PBI BIOS is enabled. A complete description of the configuration layout can be found in the firmware technical documentation on my website.

 

Things become a little complex if the OS in use happens to disable BASIC by default or offer some other methods of BASIC control, however, since the BIOS 'BASIC Default' setting of 'Enabled' is no longer accurate if the OS happens to suppress internal BASIC regardless of how the BIOS happened to set things up. The BIOS settings could be renamed 'Disabled' and 'OS default', which would perhaps be appropriate for an OS with reverse option key functionality (which is to say, the default OS condition is no longer 'BASIC enabled'). Confusion likely prevails if the OS does anything more fancy than that.

[Faicuai]

Not entirely sure. GINTLK is going to simply shadow whatever is in TRIG3, so the most sensible option is probably testing that RAMTOP = $C0.

 

(...)

 

A complete copy of the current Incognito configuration (as stored in the DS1305's NVRAM) is stored at $D100, but the OS could only access this RAM by manipulating $D1FF and only if the PBI BIOS is enabled. A complete description of the configuration layout can be found in the firmware technical documentation on my website.

 

Things become a little complex if the OS in use happens to disable BASIC by default or offer some other methods of BASIC control, however, since the BIOS 'BASIC Default' setting of 'Enabled' is no longer accurate if the OS happens to suppress internal BASIC regardless of how the BIOS happened to set things up. (...)

 

Thanks, I will consider RAMTOP, but that would include $C0 for XL-OS and up to $D0 for OS-B/52K. Therefore, I need space for a CMP/CPX and BCS/BCC to consider the dual range. I will check on MyCopier file to see if current code structure allows that.

 

As for Basic control in XL/XE/GS OS, you may (or may not) be surprised with the fact that:

 

1. At the very top (entry) of PMI1 (perform Miscellaneous Initialization, section #1), the very FIRST thing that the OS does is to DISABLE BASIC by direct manipulation of PORTB (!).

2. Then, it checks for OPTION key only (for XL/XE load) or a JMP to patch section with OPTION+SELECT (external keyboard) check, for XEGS, which runs well for XL/XE, as well.

3. Then it comes back to either PMI3 (DISABLE Basic) or simply continue with Stage-2 full-Memory SIZING and TESTING. I could very easily adjust PMI3 code with NO change in space required, by (say reading an $FD left in $0006 by BIOS) and voila! It will do EXACTLY what the current option says (Basic ON or OFF default).

 

Just some food for thought. THANKS for the wonderful input!!!

Edited December 16, 2018 by Faicuai

[flashjazzcat]

You might be surprised to hear that I studied behaviour of the OS closely when developing the PBI BIOS, so the fact the OS toggles bit 0 of PORTB isn't surprising (I've had to boot an emulated machine in the past with a breakpoint on every write to PORTB when debugging). In any case: the first two opportunities the PBI BIOS gets to intervene in any aspect of the BASIC state is very early in the OS initialisation process (even before the screen editor device is properly opened), and again on the first SIO call issued by the OS disk boot code. The method employed for getting so much as a version notice on the screen when SDX boots is thereby fairly convoluted; the CIO handler address table is patched by the PBI INIT code to point to a wrapper function for the original target function which prints the version notice immediately after the E: device is opened. The patch un-patches the vector table on the way out. The same patch is responsible for the newer BASIC suppression method, and if neither facility (PBI version notice or BASIC disable) is active, nothing is patched.

 

BTW: I must admit to being completely puzzled by your interpretation of the contents of $3D, $3E and $3F until now, when I just looked at this post. However, neither the main BIOS nor the PBI BIOS use any of them. TRAMSZ is explicitly set (to zero) by the PBI BIOS's BASIC disable code, however, since I noticed that failure to do so when manually suppressing BASIC resulted in an improper value being left there by the OS (it's normally $A0 when there's a cart present and $C0 when there is not, and these are the values I'm seeing with a standard OS) since the OS - having already set everything up - does not expect BASIC to suddenly vanish at this point. Therefore any value the OS cannot be relied upon to recalculate afterwards has to be explicitly set.

 

I'll give some thought to the idea of feeding BIOS configuration data to the OS by leaving a copy in RAM. Doing so should not cause a problem, but on the other hand code space is tight and I object to opportune kludges which interfere with the table-driven approach to encoding and extracting the configuration records. It's worth remembering, though, that the whole point of the BASIC disable function on the main menu of the BIOS setup tool is to tell the PBI BIOS that it should attempt to disable BASIC (in order to suppress BASIC when using an OS which would normally require the Option key to be held down). If the OS were to somehow observe the same setting and manage the BASIC state accordingly, this would not prevent the PBI BIOS from intervening in the usual manner, which would create a mess of redundant functionality. The BIOS would somehow have to know in advance that PBI BIOS intervention wasn't required, and that the OS would take care of business itself. That becomes a rather complex proposition. Moreover, an OS wishing to derive data from hitherto uninitialised RAM would require some 'magic bytes' to be left there by the underlying BIOS, as well as the configuration data of interest. Since I have about a dozen bytes left in the Incognito BIOS, the scope for additional interoperability with the OS is slightly limited.

Edited December 16, 2018 by flashjazzcat

[Faicuai]

(...) The method employed for getting so much as a version notice on the screen when SDX boots is thereby fairly convoluted; the CIO handler address table is patched by the PBI INIT code to point to a wrapper function for the original target function which prints the version notice immediately after the E: device is opened. The patch un-patches the vector table on the way out. The same patch is responsible for the newer BASIC suppression method, and if neither facility (PBI version notice or BASIC disable) is active, nothing is patched.

 

(...) Therefore any value the OS cannot be relied upon to recalculate afterwards has to be explicitly set.

 

I'll give some thought to the idea of feeding BIOS configuration data to the OS by leaving a copy in RAM. Doing so should not cause a problem, but on the other hand (...) The BIOS would somehow have to know in advance that PBI BIOS intervention wasn't required, and that the OS would take care of business itself. That becomes a rather complex proposition. (...)

 

1. Trying not to forget the true essence of this thread, I took care of business with MyCopier2.1 TRIG3 / GINTLK check, and the solution was a bit more abstract (yet very effective and precise). A simple AND $02E4 (RAMSIZ) followed by BEQ $09 (exact same address offset), allows the system to test for 80, A0, C0 and D0 in ONE SINGLE stroke, thus favoring C0 and D0 values (48K and 52K). In fact, entire OS/ROM check code from $3341 to $3354 could be substituted by those four bytes alone, and would work beautifully (!) We are using the inherited accumulator value ($4C) to our advantage. The bottom-line is that the little kick-ass MyCopier2.1 utility can now be perfectly launched from either SIO, LODER or SDX on Incognito (with zero disruption of normal operation on my Ultimates-1MB!) This is pretty close from being the MOST useful high-speed, high-ram, general-purpose, almost fully auto, .ATR<=>SIO copier I have found among the mountain of garbage that I have tested (!) Mycopyr! 2.1 (incognito).zip
2. TRAMSZ is a dual-stage, dual-value variable, that begins FIRST with initial sweep of RAM (for determining its SIZE), and it is later copied to $6A and to $02E4, and then its role is redefined as a terminal cart-boot status place-holder. Once computed by OS cart-boot manager, it is never used again for anything by the OS (at least as far as I could see in many sweeps of OS code).
3. Well, the ideal scenario is that you DO NOT do anything on your end, other than posting the codes in page zero. You can do so with confidence at $007D. When the BIOS is set to "ENABLE Basic (default)", store "$FD" at $007D. When BIOS is set to "DISABLE Basic (default)", then store "$FF" at $007D. Should be about four (4) bytes of extra code on your end, right when the BIOS option is changed. The existing / redundant PBI Basic-check / disable / enable should work fine, as I presume that, in general, you should not have to make special considerations for fine-tuned OS loads besides that output byte). If you would like to quickly test (with NO other changes on your end), let me know. I will gladly assist in anything I can be useful for.

Cheers!

 

(EDIT: sorry, corrected WRONG-file previously attached. Now correct utility is there...)

Edited December 17, 2018 by Faicuai