151

(27 odpowiedzi, napisanych Sprzęt - 8bit)

Candle napisał/a:

there is no need to flash side using sdx banking register - instead, one should use side banking register - the only thing is highest meaningfull bit is negated - oopsie by FJC i suppose ;P

So the SDX register clash between SIDE1 and U1MB was deliberate? I wonder why it was changed in SIDE2?

lemiel napisał/a:

FJC - do you think now that it will be possible to flash SIDE from U1MB equipped machine?

I see no reason why not, thanks to Candle finally chiming in. I will look into it. :)

Yes: writing $20-$3F to $D5E4 provides access to banks 0-31, so I will update UFLASH accordingly.

152

(27 odpowiedzi, napisanych Sprzęt - 8bit)

lemiel napisał/a:

Grzybson ale dlaczego. FJC wprost nie odpowiedział. Candle coś przeoczył? Czy uflash ma ograniczenia? Bo wcześniejszy flasher chyba na to pozwalał.

SIDE1 and U1MB have their SDX banking register at the exact same address. Oopsie by Candle, fixed in SIDE2. Disabling SDX in U1MB (in the BIOS, NOT with COLD /N) should allow safe flashing of SIDE1, but Murphy's Law may apply. :)

153

(318 odpowiedzi, napisanych Fabryka - 8bit)

That issue was fixed by the July 2018 update. :)

I'll forward the pre-release firmware to you both shortly. Many thanks.

154

(318 odpowiedzi, napisanych Fabryka - 8bit)

If any owners of machines equipped with Rapidus/U1MB/VBXE would like to test the latest U1MB firmware update, I would appreciate it, since a strange issue has been identified with the July 2018 U1MB firmware update concerning FX Core detection on Rapidus machines. Namely, the S_VBXE driver and other software attempting to detect the VBXE FX core would fail to do so. Unfortunately the issue went undiscovered and unreported for nine months, so it doesn't seem widespread/critical, since only one person experienced it. Nevertheless, I could replicate an issue on my own hardware and was able to implement a simple fix. This fix doesn't appear to work for the person who reported the issue, however, so I would like to know if the fix rectifies things for everyone else concerned. If that is the case, then the issue on the 'unfixable' machine may be a hardware problem.

Since the issue was discovered at the last minute and I have had zero response to a request for problem reports on the AtariAge forum, I can only conclude that two machines are affected by the issue, or that no-one else is bothered about it. If I don't hear anything in a few days, the firmware will be released as is.

155

(17 odpowiedzi, napisanych Sprzęt - 8bit)

All the files are on the toolkit ATR:

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

156

(17 odpowiedzi, napisanych Sprzęt - 8bit)

OK. Latest SDX Image with SIDE.SYS and FDISK is here:

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

Current driver version is 3.5.

157

(17 odpowiedzi, napisanych Sprzęt - 8bit)

On Cobol's 130XE when SDX is USEing BANKED, SIDE.SYS will raise MEMLO by only 951 bytes since most of the code and buffers will be placed in the extended DOS bank. I just checked here by booting with SHIFT held (which prevents the SIDE driver from installing). MEMLO was $0F4C before installing SIDE.SYS, and $1303 afterwards.

Meanwhile, on a 64K machine or in any situation where SDX is running in OSRAM, SIDE.SYS will push MEMLO beyond reasonable limits. To achieve a MEMLO of $1A60 (which is well below the recommended loading address for applications) in these circumstances, one would have to omit several other drivers (ATARIDOS.SYS, etc).

158

(5 odpowiedzi, napisanych Sprzęt - 8bit)

I don't mind one way or another personally, but I find it surprising that disable functionality wasn't built in when you know a Covox option already exists in both versions of the U1MB firmware. I assume there was some rationale behind that option existing in the first place in Candle's BIOS and on his hardware. As it stands, the Covox option in the U1MB should be REMOVED (by using a different plugin) when this Covox is installed in the machine, since the option does nothing at all. :) I predict that every user who purchases the Covox will complain that the U1MB Covox disable option doesn't work. :D

159

(5 odpowiedzi, napisanych Sprzęt - 8bit)

Yes: Lotharek confirmed there is no logic-driven disable pin on his device. :(

160

(9 odpowiedzi, napisanych Sprzęt - 8bit)

OK. You'll have to check things again, then, since if you follow the instructions carefully, everything will work.

161

(9 odpowiedzi, napisanych Sprzęt - 8bit)

@PabloZP: I got a PM from you but there are no reply links and nothing in my DM inbox here so... who knows. :)

Anyway: looks like the Chroma is not connected for some reason. Did you remember the Chroma wire to the jack? Don't forget that the wire should go the trace which joins the removed R27 and C61. Maybe you connected it to the wrong R27 via, which would explain the lack of colour.

Here's the 1200XL Schematic, anyway (attached), in case it's useful:

162

(2 odpowiedzi, napisanych Programowanie - 8 bit)

Certainly, providing you don't need floating point operations or BASIC.

163

(20 odpowiedzi, napisanych Sprzęt - 8bit)

Amazing that so little software was written using the features available (despite lavish frameworks created by tebe, Drac030, etc), and yet the focus is on what's not working properly or how the device could do more. :) I would have found the ability to generate an IRQ at line x useful, but I guess we can work around these things.

164

(18 odpowiedzi, napisanych Sprzęt - 8bit)

You can use SDX on IDE Plus or U1MB, as far as I recall. The point is never to have more than one active at the same time. There are no benefits to one over the other as far as I can tell.

You'd use your SIDE2 with the switch in the upper (loader) position, and the U1MB PBI BIOS (which is perfectly usable alongside IDE Plus) will disable the loader ROM on the cartridge for you. I've had this exact setup running in the past without problems.

The CONFIG.SYS issue must be hardware related, since I tested the 1.6 BIOS in Altirra and CONFIG.SYS was read properly from the C: drive upon booting.

165

(18 odpowiedzi, napisanych Sprzęt - 8bit)

Just as I well I looked here. Command 'F' (Media Change) expects $00 in DSTATs as of 1.6 otherwise partition table refresh doesn't work. FDISK fixed...

166

(33 odpowiedzi, napisanych Software, Gry - 8bit)

perinoid napisał/a:

Bardzo fajnie to brzmi, zwłaszcza kodowanie PWM (PCM to tak sobie, mocno szumi jak dla mnie). Ale... skąd można zassać odtwarzacz Flashjazzcata? Bo przy odtwarzaniu z pamięci to wiele się nie udaje odegrać - nawet przy 1MB RAM (niestety, player nie rozpoznaje 4MB Axlon na Amtonii, musi być ustawiony 1MB).

http://atariage.com/forums/topic/244946 ... try4032449

167

(75 odpowiedzi, napisanych Programowanie - 8 bit)

xxl napisał/a:

@flashjazzcat: and if you install the E driver: which will be faster and better, both methods will be useless, but the direct jump is faster and shorter ;-)

Why would the correct method fail when the HATABS entry points to a custom handler jump table in RAM? One of the nice things about the Atari OS is the elegant, extensible design. Look into it. :)

168

(75 odpowiedzi, napisanych Programowanie - 8 bit)

Instead of assuming the content of the OS ROM, it would be safer to simply look up the address via HATABS, whose "E:" entry points to $E400. In turn, the GET vector in the table at $E400 is $F249 (EGETCH-1). Same result.

169

(75 odpowiedzi, napisanych Programowanie - 8 bit)

Very bad practice and makes your application unusable with drivers (for example, drivers which intercept the screen handler and draw lines twice as quickly as the OS line drawing code). The entry points are unpublished because they are not entry points.

perinoid napisał/a:

Chciałem spróbować na innej karcie, ale tu jest problem z SDX. Chyba będę musiał zrobić downgrade, bo na 4.49b w Ultimate nie ma FDISK, a w 4.49c dla SDX FDISK nie uruchamia się - jest problem z załadowaniem bodajże FDISK1.OVL (czy jakoś tak, piszę z pamięci).

The FDISK.COM stub loader requires the three OVL files on CAR: to have the hidden (+H) attribute set, but this was overlooked and that's why it won't run. You can fix this yourself in the SDX Imaging tool (set +H on FDISK*.OVL), but I reminded Trub about it anyway. ;)

171

(30 odpowiedzi, napisanych Sprzęt - 8bit)

Yes: that part seems to correspond with what's in one of my boards. :)

172

(30 odpowiedzi, napisanych Sprzęt - 8bit)

Montezuma napisał/a:

I fully agree, but knowking that, a few months ago I have ordered extra cables from Lotharek to rescue the black U1MB.
I tested it with the new cables and it still had issues.
Now my new white U1MB works well. I'm happy and do not want to see the black one again !
I have actually sent it today to Jürgen from ABBUC. Perhaps he can repair it and use it...

I see. In that case, one extra thing I can point to is the PLCC flash ROM used on the older (black) board. They were usually Amic (occasionally AMD too?) chips and sometimes replacing the flash ROM with an SST part can make a very big difference to system behaviour (as much as turning a non-booting system into one which works).

Anyway: thanks for positive feedback on firmware. You'll finally see an update this week, I promise. :)

173

(30 odpowiedzi, napisanych Sprzęt - 8bit)

Rapidus does not appear to discriminate between U1MB board revisions. I built a couple of U1MB/Rapidus machines for people and the one with the white U1MB worked just as badly as the one with an older Candle board. However, I recently tested my Rapidus in a 1088XEL (with white U1MB) and the fact it works quite reliably there (despite the presence of U1MB, which is usually automatically blamed for problems even if the machine worked 100 per cent stably prior to Rapidus' arrival) suggests to me that the ground and power planes on the 1088XEL make a big difference to stability.

Problems with cartridges where U1MB is present (especially if issues follow upgrades from one machine to another) may suggest breaks in the RD4/RD5 lines on the MMU cable. I had one 800XL sent back which would not recognize cartridges at all, but worked perfectly well after the MMU cable was replaced.

174

(49 odpowiedzi, napisanych Software, Gry - 8bit)

Well, BIOS update 1.5 certainly made the XE throw up (unless the towering instability off what's hanging off the ECI caused communication issues), but the 600XL is still going strong:

https://preview.ibb.co/h2SUCn/IMG_20180309_190836520.jpg

EDIT: XE worked after I cleaned IDE Plus's ECI pads with Isopropyl alcohol. :)

175

(49 odpowiedzi, napisanych Software, Gry - 8bit)

What? So IDE+ BIOS 1.5 crashes OS and smashes communication with a real newdev device? I must try it. :)