U1MB, Incognito, SIDE2, SIDE3, 1088XEL/XLD Firmware 4.0 Released

[+Allan]

2 hours ago, _The Doctor__ said:

with the caveat that sometimes a substitution was done by a factory or penny pinching buy of chips... slightly out of spec for the machine but good enough to get the things out the door and the order filled. Sure they worked and barely passed the basic tests, but it did cause issues for PBI/ECI/and expansion card/card edge pick offs. We aren't talking a re work of the board or architecture here. Just a replacement of an out of spec chip for our dear machine.

My guess would be that if Warner Atari had been able to continue on and came out with the 1090 in large numbers, they would have had issues with 1090 cards not working with some 600XL, 800Xl and  130XEs. They would have most likely have figured out the timing issues and had people bring their computers to their local Atari Service Centers and have their 74LS08 replaced with 74F08 or whatever other issues they had. Atari was used to this and this is why they created the Service Centers. For example, when the 5200 VCS adapter came out, they didn't work with the 4-port 5200s. They figured out a simple mode to the board and had people bring in the 4-ports to mod them. I had my 4-port modded by a service center back in late '83. 

[Faicuai]

34 minutes ago, Allan said:

if Warner Atari had been able to continue on and came out with the 1090 in large numbers, they would have had issues with 1090 cards not working with some 600XL, 800Xl and  130XEs.

Well, most recent 1090-remake efforts clearly suggest that a solution like the 1090 seems to have been either designed or better suited to the 1400XL and 1450XLD, where those MoBos offered on-board buffering for some key lines of their PBI ports...

 

Neither 600XL / 800XL / 130XE came with such buffering, as they are stripped-down HW versions. In other words, cheap and cheaper.

[flashjazzcat]

I think all A8's are technically 'out of spec' in one way or another, but an issue which (in my experience) requires a 'fix' on the base machine more than fifty per cent of the time cannot really be retrospectively blamed on the quirks of the target platform. I say this as someone who would have no idea where to begin designing hardware or writing VHDL, BTW.

 

Regarding the loader: I am now fixing the issues in the 'big' (internal loader) FAT driver which weeks ago got fixed in the little (CIO) driver, with a view to releasing something when this is done. Fair warning, though: the big driver is 6,000 lines long and the short driver has been subject to a catalogue of optimisations and fixes which I can either port verbatim back to the big driver (momentarily breaking everything in the process, I imagine), or pick through the big driver and fix the issues in an ad-hoc fashion. The second option is quicker, but the first option is more pragmatic and will result in code which is far easier to maintain.

 

Expect this to take a little while, anyway, since it represents a shed load of work regardless.

Edited October 23, 2021 by flashjazzcat

[_The Doctor__]

1 hour ago, flashjazzcat said:

I think all A8's are technically 'out of spec' in one way or another, but an issue which (in my experience) requires a 'fix' on the base machine more than fifty per cent of the time cannot really be retrospectively blamed on the quirks of the target platform. I say this as someone who would have no idea where to begin designing hardware or writing VHDL, BTW.

 

Regarding the loader: I am now fixing the issues in the 'big' (internal loader) FAT driver which weeks ago got fixed in the little (CIO) driver, with a view to releasing something when this is done. Fair warning, though: the big driver is 6,000 lines long and the short driver has been subject to a catalogue of optimisations and fixes which I can either port verbatim back to the big driver (momentarily breaking everything in the process, I imagine), or pick through the big driver and fix the issues in an ad-hoc fashion. The second option is quicker, but the first option is more pragmatic and will result in code which is far easier to maintain.

 

Expect this to take a little while, anyway, since it represents a shed load of work regardless.

I could see you transitioning quite well into designing hardware and writing the hardware descriptors, touch a little PASCAL, route around in ADA, then grab a couple VHDL manuals and you'd be there. I think you're more capable than most to do this!

----

While I hear the either or approach, inevitably, the two are always intertwined. I think it's always going to be done in parallel... if not on the editor then at least within the mind. Taking from one and transplanting it to the other in different ways.

Edited October 23, 2021 by _The Doctor__

[flashjazzcat]

Method 2 will get done anyway; it just depends if I release a fixed-up version which is 'good enough' for testing.

 

As for hardware: it becomes harder and harder to acquire new skills the older one gets, but if I had the time and inclination, maybe. Fortunately it's not currently necessary, at least as long as Candle is designing excellent hardware for which I am tasked with writing firmware.

[cathrynm]

On 10/23/2021 at 9:25 AM, flashjazzcat said:

I think all A8's are technically 'out of spec' in one way or another, but an issue which (in my experience) requires a 'fix' on the base machine more than fifty per cent of the time cannot really be retrospectively blamed on the quirks of the target platform. I say this as someone who would have no idea where to begin designing hardware or writing VHDL, BTW.

 

 

I've been poking around the Mister Atari 8bit core, basic since I kind of still know the hardware, and I'm curious about FPGA. It's mostly VHDL.  I'm just tweaking easy things for now, making simple changes. There's some of this that is just sequential, like programming, really, and obviously there are bits that are not. Main thing that's a hassle is that the compile times are pretty brutal. I have medium-new PC here, 8 cores, and it still takes 10s of minutes to build.  Right now, just dealing with syntax issues.  I still keep typing '==' instead of '=' and '=' instead of '<='.

[flashjazzcat]

5 minutes ago, cathrynm said:

I've been poking around the Mister Atari 8bit core, basic since I kind of still know the hardware, and I'm curious about FPGA. It's mostly VHDL.  I'm just tweaking easy things for now, making simple changes. There's some of this that is just sequential, like programming, really, and obviously there are bits that are not. Main thing that's a hassle is that the compile times are pretty brutal. I have medium-new PC here, 8 cores, and it still takes 10s of minutes to build.  Right now, just dealing with syntax issues.  I still keep typing '==' instead of '=' and '=' instead of '<='.

Candle sends me bits of VHDL from time to time to describe hardware behaviour, and I sort of understand it.  The main thing I have to keep in mind is that it's a description of parallel logic, not procedural. I've also vicariously suffered the mistery he's experienced with compiler changes, causing all kinds of warnings to be spat out, resource alerts, odd behaviours, etc.

[ivop]

7 minutes ago, flashjazzcat said:

Candle sends me bits of VHDL from time to time to describe hardware behaviour, and I sort of understand it.  The main thing I have to keep in mind is that it's a description of parallel logic, not procedural. I've also vicariously suffered the mistery he's experienced with compiler changes, causing all kinds of warnings to be spat out, resource alerts, odd behaviours, etc.

A few years ago I experimented a bit with a CPLD and an FPGA experimentation board, but I soon discovered that it was not for me either. It's either a bunch of 74xx logic like PAL/GALs BITD and they operate in parallel. Or it's more advanced and stuff is triggered by the 100+MHz clock, and a slightly delayed one, and one slightly more delayed, et cetera...

 

Or they even load a CPU core, and run code on that. So why not use a CPU in the first place? That's why I like the UNO Cart design (bus sniffing) more than the AVG cart design, even though the AVG cart has more functionality. That one is pretty cool, too. With a SIO connector, and now ECI/PBI support!

[flashjazzcat]

And we never tire of hearing about it.

 

But at the end of the day, I'm more interested in what the 6502 can do than what a modern MCU can do, and the sparser the external logic, the better.

 

 

 

[Estrayk]

Hi flashjazzcat.

I just bought a SIDE3 and I am very happy with it. Before I had a SIDE2.
But I'm sure that with the SIDE2 I could load some .ATR that now not. For example this:

 

https://demozoo.org/productions/298679/

 

I get this error:

Error: ATR too big (180k max)

Can you test it please? Can be a bug with the new 4.0 firmware?

(ATARI XE + Ultimate 1Mb + Dual Pokey + VBXE)

Edited November 3, 2021 by Estrayk

[flashjazzcat]

40 minutes ago, Estrayk said:

Error: ATR too big (180k max)

You haven't installed the SIDE3 PBI BIOS (and U1MB SIDE3 plugin), or have the HDD turned off in the U1MB settings. You're therefore using the quite limited stand-alone ATR support.

Edited November 4, 2021 by flashjazzcat

[Mazzspeed]

41 minutes ago, Estrayk said:

Hi flashjazzcat.

I just bought a SIDE3 and I am very happy with it. Before I had a SIDE2.
But I'm sure that with the SIDE2 I could load some .ATR that now not. For example this:

 

https://demozoo.org/productions/298679/

 

I get this error:

Error: ATR too big (180k max)

Can you test it please? Can be a bug with the new 4.0 firmware?

(ATARI XE + Ultimate 1Mb + Dual Pokey + VBXE)

Runs fine here. SIDE3/U1MB all latest firmwares...

 

[Estrayk]

Okay, I'm idiot. It did have the PBI Bios enabled, but I did not know that it was necessary to have the Hard Disk in Enabled.
Sorry to both.

 

Now, it works like a charm. thx

Edited November 4, 2021 by Estrayk

[+bf2k+]

I have a U1MB with the latest firmware 4.0 and a SIDE 2 cart.

 

In my APT table (FDISK 4.85), I have disks C: thru O: setup... O: is a DD512 with 65535 sectors.  When I formatted it, I named it "HD15-O".  When I look at O: in DOS now, the volume name has changed to "X Disk O" and it only has 3776 secs.  It is changing to this volume name all by itself... this has happened a least 4 times in the last 36 hours and I don't know why.

 

Clues?

[_The Doctor__]

12 minutes ago, bf2k+ said:

I have a U1MB with the latest firmware 4.0 and a SIDE 2 cart.

 

In my APT table (FDISK 4.85), I have disks ? thru O: setup... O: is a DD512 with 65535 sectors.  When I formatted it, I named it "HD15-O".  When I look at O: in DOS now, the volume name has changed to "X Disk O" and it only has 3776 secs.  It is changing to this volume name all by itself... this has happened a least 4 times in the last 36 hours and I don't know why.

 

Clues?

yes you need to turn off your ram disk

edit the startup.bat, config.sys etc... take out or rem ; ramdisk lines

I keep both types of sparta dos on the disks replicating them as closely as possible to my SDX environment is about the same as my SD3.x versions.

 

Edited November 11, 2021 by _The Doctor__

[+bf2k+]

Is that in the SIDE cart?

[flashjazzcat]

If you're confused about which APT partitions are actually recognized as such under DOS, use the LSDSK tool. It's on the APT Toolkit disk:

 

https://atari8.co.uk/apt/toolkit/

 

The tool is also built into the CAR: device on some of the U1MB ROMs.

 

[flashjazzcat]

Just now, bf2k+ said:

Is that in the SIDE cart?

Remove 'DEVICE RAMDISK' in CONFIG.SYS on the CAR: device (which requires editing of the SDX ROM using the SpartaDOS Imaging tool), or make a new CONFIG.SYS on SDX boot partition (set with the 'CONFIG.SYS' setting in the U1MB setup menu) which lacks the 'DEVICE RAMDISK' line.

 

[+bf2k+]

Makes perfect sense.

 

I will duplicate the CONfig.sys in CAR on my boot drive and remove the RAMDISK entry... thanks!

 

 

Worked perfectly...

[_The Doctor__]

Just now, bf2k+ said:

Makes perfect sense.

 

I will duplicate the CONfig.sys in CAR on my boot drive and remove the RAMDISK entry... thanks!

I do this in the spartados x cartridges user space area of it's romdisk as well as on the disks themselves. In the event that something gets in the way of one or the other, it will always have my chosen base config.

[Brandhotte]

Hello, everyone,

 

Who can help ? I'm trying to flash my new SIDE3. But don't get it. So far, my SIDE2 worked without any problems.
Have already downloaded the file several times but it seems like it is too short. When deleting, it sometimes shows me timeout, sometimes not.

In spite of this, he starts flashing on the benches. But that stops at bank 32. What am I doing wrong ?

Times have attached 2 pictures.

Many greetings Brandhotte

[Jacques]

Hi @flashjazzcat,

is there a chance future version of SIDE3 firmware supports Bomb Jack/Jake image of Corina cartridge, please? I attached two images, both supposedly of cart version of BJ, when tried to run from SIDE3 loader, one produces an error "Type 75 not supported", another "Type 80 not supported". The second file (bj_corina.bin) has been recently shared by @tebe on atarionline.pl forum, the first one I found in the past elsewhere.

Thank you for all the incredible stuff you do.

bj.bin bj_corina.bin

Edited November 19, 2021 by Jacques

[flashjazzcat]

6 hours ago, Brandhotte said:

Have already downloaded the file several times but it seems like it is too short.

This isn't a timeout reading the file, I would say, but the Flash ROM timing out (i.e. failing to read back the programmed value after a pre-determined number of 'retries'). This would suggest a fairly serious hardware timing issue. Try the same operation on a different A8 if possible; that's the fast way to diagnose the matter.

4 hours ago, Jacques said:

is there a chance future version of SIDE3 firmware supports Bomb Jack/Jake image of Corina cartridge, please?

Types 75 and 80 are right out in the weeds at the moment. From the emulation table in the loader sources, I see that nothing beyond type 63 is implemented, aside from type 75 (AtariMax 1Mbit, bank 0; put there to support one of the PoP images which won't work if the last bank is enabled by default... sigh), which itself is provisional (and clashes with one 'Corina' type) and not canonically defined (at least discussion with Avery leads me to believe this).

 

I'm having a look to see if it's even possible to emulate this cart type, anyway.  And thanks for the kind comment.

Edited November 19, 2021 by flashjazzcat

[Brandhotte]

Hello Jflashjazzcat,

 

That was it. I flashed the SIDE3 with a 130XE (without U1MB). When starting the SIDE 3, the loader is now also loaded. I don't get an ATR file included. if I press the return key on the ATR file, the 130XE restarts, but does not find anything and then works in the self-test. I then tested it on the 800XL with the U1MB. The ATR file can be integrated there. But after the restart, the red LED on the SIDE lights up and there is only a loud whistling sound and the computer remains in this state. XEX files can be started from the SIDE without any problems.

 

Brandhotte 

[flashjazzcat]

1 hour ago, Brandhotte said:

That was it. I flashed the SIDE3 with a 130XE (without U1MB). When starting the SIDE 3, the loader is now also loaded. I don't get an ATR file included. if I press the return key on the ATR file, the 130XE restarts, but does not find anything and then works in the self-test. I then tested it on the 800XL with the U1MB. The ATR file can be integrated there. But after the restart, the red LED on the SIDE lights up and there is only a loud whistling sound and the computer remains in this state. XEX files can be started from the SIDE without any problems.

ATR support is limited without U1MB, since it relies on a RAM-based OS which will be easily disrupted by software which writes to PORTB.

The U1MB machine, meanwhile - especially if it is also an XE - might benefit from replacing 74LS08 with a 74F08, this being a canonically effective fix for stability/lock-up issues with SIDE3. Of course it would be preferable to address this issue 'on device', but despite having a machine which exhibited this exact issue on his desk some months ago, the hardware developer was unable to accurately reproduce SIDE3-dependent issues reported by the owner (and was thus unable to investigate them). The developer did, however, observe stability issues on the machine, and - by substituting the 74LS08 chip - was able to correct them.

 

References:

 

 

Edited November 20, 2021 by flashjazzcat
Corrections/references