Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TileT Przeglądarkowy edytor map stworzony specjalnie z myślą o trybie tekstowym z kolorami i kwadratowymi pikselami
FujiNET firmware v1.5.0 Nowa wersja firmware, która wprowadza szereg ulepszeń i poprawek.
Prima Aprilis Compo 2025 Wystartowała nowa edycja Prima Aprilis Compo, w której obowiązuje jedno wyzwanie - piszemy wyłącznie w Atari BASIC.
maxYMiser FM v1.67 Nowa wersja trackera.
Echa Forevera 23 Wyniki konkursów dla platformy Atari.
atari.area forum » Posty przez flashjazzcat
New firmware works perfectly well with the CPLD code supplied on all Lotharek boards. Only the very old (v.1) JED requires an update prior to flashing my firmware, since it relies on IORAM at $D1xx and $D5xx which is not present in the v.1 JED. If you have a black U1MB board without RD4/RD5 current limiting resistors on the PCB, check first.
My firmware has no issues booting the machine in 1088K mode, so certainly look to the hardware or CPLD programming for issues.
Boogie Nights is a simple fix. Using the new U1MB/Incognito firmware, enable the PBI BIOS, and then set 'BASIC state' to 'disabled' on the first menu. It seems the demo simply fails to disable internal BASIC, but I have no explanation for why it works without holding down 'Option' on stock machines. In any case, it booted perfectly via SIO2SD on my U1MB 600XL, even using the high-speed SIO driver built into the newer U1MB firmware. :)
Of course regardless of BIOS settings, it loads from SIO2SD if you just hold down the Option key too.
Thanks for the info. :) Will have a closer look at Boogie Nights... seems intriguing.
It would be useful to know which Incognito firmware is being used and whether or not internal (PBI) high-speed SIO is enabled for those titles which fail to load via SIO2xxx devices. Regarding the problem titles, most or all exhibit identical behaviour on U1MB systems (which is hardly surprising given that Incognito's XL/XE mode emulates exactly the same operating environment).
1. Boogie Nights (XEX) may be incompatible with the SIO2SD boot loader. I don't have SIO2SD to hand right now, so can't confirm.
2. Overmind (ATR) hangs on an U1MB when run from the CF card too. Possibly it relies on some property of being loaded from a serial peripheral.
3. Bitter reality (ATR) encounters a disk error on an U1MB machine when run from the CF card, probably also because it provides its own built-in serial loader.
4. Phantasy (ATR) crashes when loaded from the CF card on an U1MB machine (reasons unknown).
Any ATR which chooses to load itself via a custom SIO loader will always fail when launched from the CF card. The ATR handler is only compatible with software which employs standard calls to DSKINV/SIOV.
Previous version ran on U1MB/Rapidus machine in 65C816 mode and on emulated 65C816. What was the issue?
New XEL-CF3 board for Rapidus owners:
https://www.youtube.com/watch?v=6dBH3ij6-1Q
I take it this board ships with the stock ROM? Speed appears to be ~38K and SDX reports a parameter error when formatting 80 Track DS/DD, although it DOES format at this density:
https://youtube.com/watch?v=Eak5m875sEk?t=938
HyperXF ROM would fix this?
VBXE emulates GTIA, so the RGB video output will not care whether the GTIA is buggy or not.
In the interests of clarity: I have NOT released this version of UFLASH yet since using the external SIDE banking register was not as easy as made out, at least in the context of this particular tool and the way it operates.
Good - well figured out. :)
I suspect BASIC is switched off somewhere else, perhaps by ATRs themselves, MyPicoDOS, etc. Possibly even a patched OS with reverse Option logic? I even searched Google and in all articles I found, it was said that Option must be held to disable BASIC with SDrive, unless the ATRs themselves have provision for automatically disabling BASIC.
Is this the same source code?
Karta CF zainicjowana starszą wersją FDISK'a, a aktualny twierdzi, ze partycje APT należy zrobić raz jeszcze. Litości...
Partitions must be contiguous with the more recent versions of FDISK. Likely there was dead space on the disk. It's unfortunate, but you can back up the partitions and reinitialise the card.
It's now possible to safely flash an original SIDE1 via UFLASH on an U1MB machine; I'll be releasing the updated version of the tool after further testing. Effective as Candle's workaround of flashing the cart via the external cart register is (in order to avoid the U1MB SDX register clash), flashing an U1MB ROM with a SIDE1 plugged in still seems an extremely bad idea. I would like to see the workaround for that which does not involve pulling the cart out of the machine.
Very nice!
Yes: and that exact solution (f08) was tried in this case and didn't work.
Using Candle's suggested signal locations and mounting the board in the sensible place (i.e. directly above the OS ROM socket) ensures that wires are as short as they can possibly be on the XL. Attaching wires direct to IC legs may work in the majority of situations, but clearly it didn't in this case (which should on its own give pause to the distributor), and when the CPU is socketed anyway (as it commonly is on an XL), wires soldered to the legs looks particularly nasty. :)
@xxl: czy ktoś oprócz ciebie korzysta z mapRAM?
This forum needs a 'like' button. :)
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?
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.
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. :)
That issue was fixed by the July 2018 update. :)
I'll forward the pre-release firmware to you both shortly. Many thanks.
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.
All the files are on the toolkit ATR:
OK. Latest SDX Image with SIDE.SYS and FDISK is here:
https://atari8.co.uk/apt/side/
Current driver version is 3.5.
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).
atari.area forum » Posty przez flashjazzcat
Wygenerowano w 0.019 sekund, wykonano 43 zapytań