Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
Opcje wyszukiwania (Strona 6 z 15)
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.
Pin napisał/a: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.
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. :)
Sikor napisał/a:@xxl: czy ktoś oprócz ciebie korzysta z mapRAM?
This forum needs a 'like' button. :)
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.
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. :)
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:
https://atari8.co.uk/apt/toolkit/
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).
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
Yes: Lotharek confirmed there is no logic-driven disable pin on his device. :(
OK. You'll have to check things again, then, since if you follow the instructions carefully, everything will work.
@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:
Certainly, providing you don't need floating point operations or BASIC.
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.
Znalezione posty [ 126 do 150 z 374 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.022 sekund, wykonano 56 zapytań