drac030
-
Posts
2,770 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by drac030
-
-
I wonder if the Maria registers could be moved in the case it was going to used in a computer, just like the GTIA was moved from $C000 in the 5200 or $D000 on the rest of the 8-bit line.
GTIA is quite different, it has the ChipSelect line which (as I understand it) makes it possible to decode the chip's hardware registers anywhere you want. But not all chips behave like this: ANTIC, for example, decodes itself on its own, simply listening to the addresses appearing on the address bus, so you cannot relocate it from $D4xx without redesigning its (ANTIC's) internals. AFAIK, MARIA has exactly the same issue, it decodes itself on its own, and does not have the CS line.
Also the Ataris' operating system probably would have to be adapted to drive the Maria chip anyway and the CIO and other zero page stuff could have been relocated outside the Maria area.Not possible. The conflicting area is ZIOCB, which meant, that, for starters, you'd need to rewrite just about all of the CIO device drivers - which mainly means just about every existing DOS.
Even if you do that (which is quite unrealistic), the second problem is that there is really no place to relocate the ZIOCB to.
-
I did hear rumours that Atari were looking at making the original xe series 7800 compatible by sticking in a 'maria' chip...i wonder if proto's exist of this m/c
I doubt. I've got an impression, that fitting MARIA into XL/XE is rather hard, because the chip keeps its registers on the zero page, conflicting with the CIO, and also on the 6502 stack area limiting its size.
-
-
-
Tezz: the software is being written and as it is done, the board is being debugged. It for example turned over, that the on-board RTC is inaccessible. The author is fixing such minor flaws now, apart of it the unit I have works very good. I have no idea, when it will be available to get, at what price etc. - these are things the author should be asked about.
Gunstar: the turbo board is an external device, it only plugs into the Atari expansion port and into the motherboard as said above. There is no reason why it should not be compatible with existing RAM upgrades. Basically, as you said, the turbo board has its own memory, and Atari has its own memory (possibly expanded the standard way). These areas remain separate.
There is an operating mode of the board, that sort-of replaces the 64k of Atari memory with the board's memory. This works so that a part of the turbo board memory effectively works as a write-through cache for the first 64k of Atari address space. But, this applies only to *main* 64k of Atari memory. Any expansions (like additional 64k in 130XE banks) won't be cached, so accesses will be slow (still averagely 20% faster than without the board, it has to be said).
ROM upgrades are not a problem either, the boards has its own separate ROM, but normally it boots off the Atari ROM, whatever is in the computer. There are three modes, you can select with a switch in which mode the board should "wake up" when powered up:
"Normal" - this is like the Warp4 board, the memory that resides in the first 64k ("old", i.e. Atari memory, main RAM, ROM, BASIC, RAM banks etc.) is slow (1,77/1,79 MHz), everything else operates at full speed. In this mode the board boots off the Atari ROM.
"Fast" - similarly, the board boots the Atari ROM, but the first 64k memory is cached. This needs special OS (like mine) to operate best, as the OS has to configure the onboard MMU at startup.
"Software" - this is identical to the "Fast" mode, except that the board's internal ROM is booted.
A very nice and powerful device, generally.
-
A RAM disk like the MIO 1 MB would be great.
What you need the ramdisk for?
-
well, is the fixed version available?
Not yet. The version with fixes is 4.40, which is to be released really soon, but not today
-
Can someone clarify a question for me. Can I use the binary ROM image for 4.39 and program to an EPROM for use in my Spartdos X cart?
Not directly. The original 4.20/4.22 cartridge is 64k, 4.39 is twice as big (128k). So some modifications have to be done, I am not even sure, if the original cartridge can be easily modified for that. Try asking via private mail the SDX Upgrade page maintainer ( http://trub.atari8.info/index.php3?strona=...upgrade_en.html ), he should know more about hardware issues.
-
This is fixed already.
-
Funnily enough, the 800XL only has the Atari logo on the label on the underside with the serial number.
Out of these listed in your sig? Sure.
As for Atari XL and XE computers, I think most of them (all?) have Atari logo and serial number on the underside label.
-
I have been trying to get the spartados update from http://trub.atari8.info/index.php3?strona=...upgrade_en.html to work on an 8MB maxflash cart...no luck. It seems to burn fine, but upon reboot it hangs. The image is sdx439rc_maxflash8mb.atr Has anyone had any luck with this, or is there a known issue?
There is an issue: the default CONFIG.SYS loads the R-Time 8 driver (CLOCK.SYS), and this searching for the RTC causes the Maxflash to switch its banks unexpectedly (for the DOS). It somehow works with Maxflash 1 Mb, but never with the 8 Mb version, AFAIK.
To work this around, make own CONFIG.SYS file, as such:
USE BANKED
DEVICE SPARTA
DEVICE SIO
Save it to the main directory of your boot disk (must be SpartaDOS formatted), and reboot. The DOS should now load your CONFIG.SYS instead of the default CAR:CONFIG.SYS, and so the problem with the R-Time driver should be avoided.
-
Yes, Basic comes up fine
So, if it goes directly to the memory test, this means that the ROM fails the checksum. 800 OS "works fine", because AFAIK it does not calculate checksums
I thought that perhaps the FP ROM got permanently disabled (this is where the PBI goes into), but BASIC wouldn't work then. It may be, that the damage appears in one of the places the 800 OS really doesn't use, i.e. $C000-$CFFF and SelfTest itself. If so, the left bar out of the two for the ROM in memory test should get red (or something).
-
-
This computer will boot fine from a floppy so long as as I use an 800 OS
Can you check, when you boot it with the 800 OS, if the Atari BASIC works?
-
I don't have XEP80 myself, but AFAIK, the XEP80.SYS driver included with the SpartaDOS X doesn't disable Antic.
-
I have no idea. The most difficult thing to emulate is custom chips, not the CPU anyways.
-
Nobody said the BlackBox was a serial device, it looks to me like the point was that the Atari supports at least 26 drives using the PBI. This shows that neither the OS ROM or DOS are limited to 4 or 8 drives.
This shows nothing, because PBI devices are not handled directly by the OS-ROM (it only enables the PBI ROM and hands over the control to it). As it was already pointed out twice (or more?) in posts above, the PBI devices thus can have up to 256 units ("partitions"), and - separately - SIO limits were discussed, which don't apply to PBI, and vice versa. So, if someone comes, cites the post where it is said that SIO is limited to 16 drives, and puts an example of the BB allowing 26 drives as a counterargument, I can only assume, that he does not follow the argumentation accurately enough.
As for SIO - _serial_ drives - the OS ROM is obviously limited to 16 units per device, because the SIO protocol is defined so by its designers: in a command only 4 bits carry information about the unit number.
-
As all the European 65XE's shipped with the bad GTIA,
Nope, I have European 65XE and the GTIA it has is good.
-
Since when the BlackBox is a serial device and so SIO limits apply? See post #10.
-
I thought he asked about illegal opcodes in 6502.
-
If programmers mainly used illegal opcodes to stop dissasemblers checking out their code then these programs, games and demos could even be patched to fix this then so they run fine on both?
Some can. Or, perhaps, even all can be fixed, but not everything is worth the necessary effort.
-
Is there a good reason to use illegal opcodes? Is it possible to make faster code (in some situations) by using them?
Few can be of some use, yes. But it is not deadly advantageous, as you can see from the percentage of programs actually using them. Moreover, a part is used apparently not to make code faster or shorter, but to make disassembly more difficult.
-
Btw. the 65C816 is the 16-bit 6502 version.. does the 65C816 support the full 6502 instruction set? I mean is it backwards compatible if installed? If so, it would be worth upgrading my 130xe from the stock 6502 I would think?
Depends, what do you mean for "full 6502 instruction set". The 65C816 certainly has all official 6502 instructions. The only problem may be, if a program uses illegal 6502 instructions - it won't work on 65C816 machine then, because opcodes illegal in stock 6502 are assigned to new instructions in 65C816.
From experience, I can say that very few programs actually use illegal 6502 instructions and thus refuse to run on the new processor. This is like 10 games out of 130 I tested, maybe 2 (rather old) demos out of 40 I tested, I don't recall any utility program which would have problems, but I think one or two can be found, probably.
-
How fast do you think the emulator will be in the end?
I overlooked that question. Well, it is difficult to say. On standard Atari, the 48k Spectrum emulation certainly is not a speed daemon. I expect however, that a version written specially for the 65C816 accelerator may be actually usable as a true emulator. This would obviously depend on the accelerator clock speed, and again, it is rather difficult to estimate the final result, but from the experience I got writing the 6502 version of the emulator, and from some draft 65C816 code I did, I now tend to think that at 14 MHz the emulator may be nearly as fast as the ZX Spectrum itself.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Indus Ramcharger Help
in Atari 8-Bit Computers
Posted
The "modes" 1A, 1C and 1b you mention are just densities AFAIK: single, medium and double, respectively. If the disk you have is DD, I don't think it helps the drive to read it, when you force the device to another density before.