7.16mhz 1200XL

[+bob1200xl]

"Any system you want as long as it's a 1200XL..."

 

Hmm... Your project, your way, but what would prevent it from going in an 600XL or 800XL, assuming that you get a board shape so that it is compatible? The XL14 board layout was compatible with all 3 models, wasn't it?

 

That was an issue with the original XL7 -- the pcb hung over the OS chip sockets, eliminating the possibility of using a different OS that that is thicker. (Think of the 32-in-1 or Puff 3-way OS module, whose name I can't think of at the moment.) The original had no PBI (of course it was for a 1200XL), and was 7 mHz only, IIRC. so having it 1.89 or 7.16 MHz sounds like a step forward. With a pbi interface, you would mount a CF card adapter on the pcb?

 

Anyway, glad to see you are interested in improving the original. FWIW, 7 MHz is plenty fast for 99% of user projects. Most of the time, I ran the XL14 at 7 MHz.

 

The XL7 will have multiple OS capability.

 

Yes - the XL14 fit in all three. I will try to continue that, but you won't get an internal CF card.

 

The CF card can be mounted entirely inside the 1200XL case, or so that you can plug the card from the outside.

 

Bob

 

Like this:

 

[Mathy]

Hello Larry

 

... Puff 3-way OS module, whose name I can't think of at the moment.

 

UltraSpeedPlus OS

 

Sincerely

 

Mathy

[+Larry]

I've been using the XL7 a bit the past week, trying to relearn how things work. I was wrong about the original being 7 MHz only -- it is 1.79 and 7.16. If a rom OS is used, it is 1.79; if the OS is run out of ram, then it is 7.16. Here are several runs of Ahl's benchmark that show the differences:

 

Atari Basic rom + rom OS -- 370 sec.

Atari Basic rom + ram OS -- 117 sec.

Atari Basic ram + ram OS -- 106 sec.

 

Naturally, the more modern versions of Basic would be significantly quicker.

[flashjazzcat]

Jon? How do these things that Michael is talking about work? Obviously, the SIDE2 cart is not PBI...

No: the SIDE cart isn't a PBI device, but it may be driven by a PBI device handler built into the Ultimate 1MB. The PBI handler (usually) disables the ROM on the SIDE cart and simply drives the IDE registers which appear near the top of $D5xx. The PBI ROM's device ID is selectable in software (0, 2, 4, or 6) and may be disabled entirely. There's 8K of banked ROM which appears in four chunks at $D800-$DFFF, and the normally inaccessible base RAM under the hardware area ($D1xx, $D5xx, $D6xx and $D7xx) is used as PBI RAM since no externally connected PBI device should do likewise (the U1MB's PBI device coexists perfectly well with devices like IDE Plus 2.0 providing each has a unique device ID). Using base RAM in this manner allowed the PBI facility to be retro-fitted via firmware (the earliest U1MB devices used only a small portion of IO RAM for the BIOS setup menu and that was all), bearing in mind there's only 1MB (2 x 512K) of discreet SRAM on the board and all of that is required for the extended memory at its maximum capacity.

 

In the case of Michael's 1088XEL and XLD boards, the U1MB PBI BIOS is used to drive the XEL-CF device, whose IDE registers have fundamentally the same layout as those of SIDE, but which reside in the $D1xx region (since the XEL-CF is not a cartridge). In this scenario, the PBI firmware is capable of driving twin physical disks (CF cards) using a suitable dual-slot adapter. APT partitions hosted on either or both physical cards may be simultaneously mounted, as may ATR files residing in FAT16 or FAT32 partitions on either or both cards. SIDE (and Incognito) media is organised in exactly the same way, using the same MBR-protected partitioning scheme, and media from one device is 100 per cent compatible with all others. So one may use the same formatted and partitioned cards with a SIDE cart, a SIDE/U1MB machine, a 1088XEL, or an Incognito 800. The firmware API (via SIO calls) is identical on all platforms, enabling the same partition editor to be used with all compliant devices.

 

Latterly, the PBI BIOS (which was initially concerned solely with driving HDD partitions and mounting FAT-hosted R/W disk images) was enhanced to include an OS-agnostic implementation of Matthias Reichl's HSIO driver and an RTime-8 compatible "Z:" driver (enabling software designed for RTime-8 to interface with the U1MB/Incognito DS1305 RTC), among other minor improvements. The other firmware components of the U1MB include the main BIOS setup utility and the XEX/ATR loader, the latter being virtually identical to the stand-alone loader found on the SIDE cart (although the latter becomes entirely redundant on an U1MB machine, since the loader is integral to the U1MB).

 

The DS1305's battery-backed user RAM is used to store configuration data which is accessed directly by the BIOS setup utility and the PBI BIOS. Three user profiles are available for rapid switching between configurations. The entirety of the U1MB firmware occupies 64K of ROM, although 24K of this is unused padding around the 2K PBI banks.

 

The system has several limitations, not least a lack of dedicated PBI RAM. This prevents the XEX loader (which requires a lot of RAM) from being called non-destructively during a session (the main BIOS setup tool may be invoked and left without disturbing the underlying contents of RAM, meanwhile). A PBI IRQ line (perhaps connected to the SIDE cart's button) would also allow fun things to be accomplished. Nevertheless, considering the hardware combo was not designed to do half the things now being asked of it, U1MB/SIDE have proved extremely versatile and powerful.

Edited April 7, 2019 by flashjazzcat

[+mytek]

Jon's explanation was so good, that I learned a few new things today .

 

To add a bit of background to what he was saying about the IDE/CF aspect of the 1088XLD (as well as the 1088XEL's XEL-CF3 add-on board), here is a schematic which gives a good break-out of the registers involved.

 

 

This also introduces the idea of a 'hardware signature', which was added to the CF3 specification to differentiate it from the earlier CF2 version. Since the U1MB BIOS can detect various hardware upgrades via a 'signature' this allows it to better configure itself to accommodate that hardware.