Atari 8bit is superior to the ST

[atariksi]

This is running a 16 colour boulderdash scroller. ( Well it's a bit of a cheat - the 16x16 characters only have 2 bitplanes per pixel, with the other 2 bitplanes constant across the whole character ) - It's enough to manage the 5th colour that the A8 offers.

It still runs in a frame - but the timing is getting a lot tighter on NTSC.

 

Just started looking at your code. Why do you have: "movem.l (a5)+,d0-d7/a0-a4, movem.l do-d7/a0-a5,0(a6)"? Is this a typo or purposely screwing with the stack in which case it would affect the cycle count...

[drac030]

The ST HDD interface is better because it's faster, dma, and has no low cpu cost. ( Did any of the HDD interfaces actually exist back in the day - when I was using the A8 the happy chip and US doubler were the 'cool' addons, and the cartridge port was for Mac65 ) I've seen the SIO2SD stuff ( which is still slow, but cool ) and I use the SIO2USB now - but I haven't got much knowledge about internal/cart mods.

 

Not to argue A8 superiority over the ST (I haven't even voted here), but, since hard drives are concerned, I'll add my 2 cents. Yes, A8 hard drives have no DMA. But decent hard drives (i.e. all except hacks) are attached to the A8 via the PBI (XL) or CART/ECI (XE) expansion port, which bare ST lacks (later MegaST has its Megabus and MegaSTE/TT have VME). That is A8 is a more open architecture and that's its advantage over the ST.

 

ST has only the cartridge port, which, AFAIK, does not allow to write data to the thing inserted (the common workaround I heard of is to use one of the address lines to provide the missing write signal, so that you get half of the cart readable and the other half writable).

 

ST has also the DMA port, which however does not look so universal as the XL/XE PBI/ECI connector: I don't think that using the DMA port you can add autobootable devices to the ST system (autobootable: i.e. the OS does not contain predefined routines to boot them), and this PBI/ECI does allow.

[Ross PK]

Technically obviously the ST is more superior, but I way way way prefer the 8-bit.

 

The OP is right, the ST just doesn't feel the same as the 8-bit at all, it really doesn't seem as though they are related to each other.

 

The ST just kinda feels souless in comparison to the 8-bit, like it's more like a traditional bland computer.

 

When I was young, I was sucked in by the flashy graphics of the ST, and sold my 8-bit to get one (I had in mind that I'd buy another 8-bit when I was able to).

 

About a week later I totally regretted it, the games on the ST just weren't as fun as the games on the 8-bit, they weren't even the same. In fact to this day there's not really many games that I like on the ST.

[Ross PK]

Technically obviously the ST is more superior, but I way way way prefer the 8-bit.

 

The OP is right, the ST just doesn't feel the same as the 8-bit at all, it really doesn't seem as though they are related to each other.

 

The ST just kinda feels souless in comparison to the 8-bit, like it's more like a traditional bland computer.

 

When I was young, I was sucked in by the flashy graphics of the ST, and sold my 8-bit to get one (I had in mind that I'd buy another 8-bit when I was able to).

 

About a week later I totally regretted it, the games on the ST just weren't as fun as the games on the 8-bit, they weren't even the same kind of games. In fact to this day there's not really many games that I like on the ST.

[atariksi]

This is running a 16 colour boulderdash scroller. ( Well it's a bit of a cheat - the 16x16 characters only have 2 bitplanes per pixel, with the other 2 bitplanes constant across the whole character ) - It's enough to manage the 5th colour that the A8 offers.

It still runs in a frame - but the timing is getting a lot tighter on NTSC.

 

Just started looking at your code. Why do you have: "movem.l (a5)+,d0-d7/a0-a4, movem.l do-d7/a0-a5,0(a6)"? Is this a typo or purposely screwing with the stack in which case it would affect the cycle count...

 

I meant screwing with (a6) by storing a5 on it since you have cycles @8*13.

[atariksi]

Hey, I've just found out that the A8 is superior to any modern quad core PC or Mac:

 

.

2. Rock solid timing and more accurate (No indeterminate signals to throw off cycle-exactness)

 

- due to 1. the timing will be less accurate

.

.

 

I'll note that more and more kit these days supports HPET timers. That's 3 to 32 continuous or one-shot timers running at least 10Mhz (if not higher). I don't doubt in the least that the A8 timers are vastly superior in some respect...

Two issues with that: (1) It's not present on most machines out there (so a non-standard timer) nor does Windows XP use it which is still predominant in the world; (2) The accuracy of it isn't 1/10Mhz; it's less given latency and other problems.

 

.

.

9. Faster joystick I/O and SIO I/O (16-bit reads/writes)

 

- no SIO port at all, and inferior joystick port (only 1 on most PCs)

 

 

Not even one on anything made after 05 for the most part. That is yet another legacy port that has been subsumed by USB. Serial and Parallel ports are on the way out too. A Core Duo motherboard I just installed has serial and parallel headers but was not supplied with ways to bring them out to ports on the case. I wouldn't be surprised to see the option doesn't exist at all on a lot of kit these days. That IS something of a minor shame as both are friendly to the home tinkerer and the best we can do henceforth is either some sort of experimenter's kit or a serial dongle for USB.

 

Parallel port is better than gameport but gameport was standard for joysticks for long time and USB sticks have to be used through some device driver due to nonstandard means of accessing the USB sticks. At least gameport had direct I/O access at 201h. USB protocol also is serial so not as fast/efficient as a parallel port or A8 joystick port.

[+poobah]

USB sticks have to be used through some device driver due to nonstandard means of accessing the USB sticks.

 

USB protocol also is serial so not as fast/efficient as a parallel port or A8 joystick port.

 

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

[frogstar_robot]

Two issues with that: (1) It's not present on most machines out there (so a non-standard timer) nor does Windows XP use it which is still predominant in the world; (2) The accuracy of it isn't 1/10Mhz; it's less given latency and other problems.

 

 

They more than suffice for aligning audio/video streams, timestamping files and events, timing control of specialty peripherals besides being apt for any number of other purposes. In absolute terms, they can time external to the PC events with vastly higher concurrency and resolution than an A8 will ever do. They probably aren't good for driving the bare metal of the display hardware but that isn't remotely apropos on a PC anymore and such applications are the remaining irrelevant refuge of an A8 timer being better. Within a few years these timers WILL be standard equipment and even the XP diehards will have to start choosing something else. USB ports, PCIe slots, and any number of other standard PC features get introduced this way. That they aren't "standard" is only a somewhat valid point now and it will become less so by the month.

 

Parallel port is better than gameport but gameport was standard for joysticks for long time and USB sticks have to be used through some device driver due to nonstandard means of accessing the USB sticks. At least gameport had direct I/O access at 201h. USB protocol also is serial so not as fast/efficient as a parallel port or A8 joystick port.

 

 

They are nonetheless "Good Enough". A joystick device only has to be faster than the human using it. We aren't going to gut USB gamepads as a way of interfacing a ComputerEyes we have laying around. Besides which a cheapo USB scanner is going to monkeystomp that ComputerEyes in every conceivable way. USB sticks usually are handled with HID class drivers. I don't see what is "nonstandard" about that.

 

You seem hung up on forms of "superiority" that are either irrelevant or when considered in a wider context aren't really big wins at all. I only ever saw one nongaming device that interfaced through a joystick port and that was a handheld scanner on a C-64; the device was fun but hardly practical. I doubt the vastly superior A8 ports would have improved it much. The one I most commonly heard of on an A8 was the XEP-80 and that was a poor impedance match at best. I've also seen the paddle input pins used as a "lie detector". Again fun but so what? ST, C-64, and A8 all had options with a variety of tradeoffs between bi-directionality, latency, and bandwidth for hobby electronics interfacing. And as for PCs these days:

 

 

http://www.robotshop...face-kit-3.html

http://www.electroni...n/interface.htm

 

and many many more options than you can shake a stick at.

 

So the A8 has great joystick ports, I'll grant you that. But I'd use the User Port on a C-64 and not even consider the joystick ports. I would use midi, cartridge, or parallel port on an ST depending on the application. You'll doubtless counter the joystick port was some sort of standard for interfacing certain kinds of peripherals and the A8 was better at it. But if being used in such a fashion then the device manufacturer will go for the lowest common denominator on all platforms nullifying that advantage. But then such issues are one major reason the PC steamrollered all these old platforms we get so passionate about. Most of us here and this includes the Atarians Just Don't Care about A8 joystick port superiority.

[Crazyace]

Just started looking at your code. Why do you have: "movem.l (a5)+,d0-d7/a0-a4, movem.l do-d7/a0-a5,0(a6)"? Is this a typo or purposely screwing with the stack in which case it would affect the cycle count...

 

I meant screwing with (a6) by storing a5 on it since you have cycles @8*13.

 

Sorry, those two lines aren't actually used anywhere - I was just sketching different routines before deciding which one to actually use

( I think I started with movem.l (a6)+,d0-d7/a0-a5 ; movem.l d0-d7/a0-a5,-(a7) - as I had a crazy thought about abusing the stack as a temporary register )

[+DarkLord]

 

ST has also the DMA port, which however does not look so universal as the XL/XE PBI/ECI connector: I don't think that using the DMA port you can add autobootable devices to the ST system (autobootable: i.e. the OS does not contain predefined routines to boot them), and this PBI/ECI does allow.

 

I'm a bit confused about this... I mean, my Mega ST boots off a 4 gig SCSI drive. My STacy boots off a 2 gig SD card... I'm not sure what you are trying to say here. Clarify? Thanks!

 

BTW, hadn't seen it mentioned - can the 8bits use CDROMs? I mean as in burn them, make audio CD's all that stuff. Thanks again.

Edited December 28, 2009 by DarkLord

[Crazyace]

I'll take a look at the code once I get some time. It's theoretically impossible to copy 4 planes for a full screen given the 68K bandwidth limitations.

 

You can stop speculating that it can be done in less than 10% of the cycles.

 

No problem, I wrote it for my info more than anything else, and then posted it so at least there would be something to back up my claim.

I'll see if I can get the Battlesquadron first level to assemble ( I couldn't fully recover one of my data discs ), as that uses vertical smooth scrolling ( 16 colours ) with roughly 20 scanlines worth of time. - Not speculation, but actual figures for a game.

...

ST has video starting address at 256-byte alignment so unless you are doing some weird tricks, even vertical scrolling would be troublesome. Compare with EGA which has video starting address on BYTE alignment.

 

Yup - it's using wierd tricks, but they work

 

To me, Sync scrolling is just as valid as the prior 0 hacks on the 8 bits, something that relies on an undocumented reliable mechanism in the hardware to give a boost to the machine capabilities.

 

Sorry, but PRIOR 0 is GTIA doing its normal operations and not a big discovery-- just type something like:

 

POKE 706,122:POKE 53263,255:POKE 53250,128

 

It has nothing to do with playing with video frequencies which has proven in history to cause problems/damage (i.e., CGA).

 

It's very dodgy, as inside the chip you're driving two outputs at the same time into a single input. I guess it just luckily works because it's NMOS ( Curt can probably correct me if I'm wrong )

Please also read up on how the sync scrolling works - it doesn't actually change the frequency going to the monitor - it just confuses the shifter into displaying more valid infomation per line - just like wide playfield on A8, but via a hack.

( Not sure about what CGA has to do with it? only talking about A8 and ST here )

[atariksi]

USB sticks have to be used through some device driver due to nonstandard means of accessing the USB sticks.

 

USB protocol also is serial so not as fast/efficient as a parallel port or A8 joystick port.

 

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

 

That's strike two, poobah. Initially you argued STs joystick ports aren't slow and now this. If I do a LDA 54016 on A8, the equivalent on PC w/USB HID would require a series of I/O instructions and no guarantee of the exact time of arrival of information. Suffice to say that HIDs use a slower protocol and you'll end up using up more time than the LDA 54016 (2 microseconds) or parallel port which is a simple IN AL,DX. Now, don't argue that speed is useless for joysticks because you would rather have a faster way of reading it and thus give more time for other things.

[atariksi]

I'll take a look at the code once I get some time. It's theoretically impossible to copy 4 planes for a full screen given the 68K bandwidth limitations.

 

You can stop speculating that it can be done in less than 10% of the cycles.

 

No problem, I wrote it for my info more than anything else, and then posted it so at least there would be something to back up my claim.

I'll see if I can get the Battlesquadron first level to assemble ( I couldn't fully recover one of my data discs ), as that uses vertical smooth scrolling ( 16 colours ) with roughly 20 scanlines worth of time. - Not speculation, but actual figures for a game.

...

ST has video starting address at 256-byte alignment so unless you are doing some weird tricks, even vertical scrolling would be troublesome. Compare with EGA which has video starting address on BYTE alignment.

 

Yup - it's using wierd tricks, but they work

...

If it's not S.Y.N.C. based, let's see it.

 

To me, Sync scrolling is just as valid as the prior 0 hacks on the 8 bits, something that relies on an undocumented reliable mechanism in the hardware to give a boost to the machine capabilities.

 

Sorry, but PRIOR 0 is GTIA doing its normal operations and not a big discovery-- just type something like:

 

POKE 706,122:POKE 53263,255:POKE 53250,128

 

It has nothing to do with playing with video frequencies which has proven in history to cause problems/damage (i.e., CGA).

 

It's very dodgy, as inside the chip you're driving two outputs at the same time into a single input. I guess it just luckily works because it's NMOS ( Curt can probably correct me if I'm wrong )

Please also read up on how the sync scrolling works - it doesn't actually change the frequency going to the monitor - it just confuses the shifter into displaying more valid infomation per line - just like wide playfield on A8, but via a hack.

( Not sure about what CGA has to do with it? only talking about A8 and ST here )

 

It's not dodgy; it works consistently. And the code above proves that the PRIOR 0 mode is DEFAULT. I didn't have to alter the PRIOR register to get the ORing to take place as the default setting of location 623 is 0. If it were dodgy, you would think the OS would have put some other value than 0 into 623 at startup. I have read other things regarding SYNC (for ST, CGA, and other machines) and CGA was an example which modified the frequencies of monitor to get new graphics/text modes (or mixed versions) that led to the damages of many monitors.

[Crazyace]

I wasn't going to reply, but I guess I did invite the response

 

Sorry, but A8 graphics modes are full-screen. So whether A8 does 320*200 or 80*200 or 40*25, they are all full screen (and can be more w/overscan). And don't forget the mixing of modes like doing GTIA + Gr.8 on one scanline.

A8 graphics modes are also lores - but I was being pedantic about the quarter screen , so I'm not going to use that argument as an advantage for ST.

Does mixing modes work with scrolling as well? ( In software it's a bit trivial for the ST - but I've never looked at whether you could switch 320-640 mode in the middle of the screen )

 

( Also GTIA on the A8 wasn't launch, maybe I should compare an ST model with blitter for timings )

...

STe was when people already went for Amiga/PCs. GTIA was when 8-bit was still peaking and natural upgrade (backward compatible). If ST had been compatible with A8, nobody would be debating this issue.

I was thinking MegaST for blitter , but you're correct, most A8 machines had GTIA, - and all of the scrolling was present on CTIA only. I'll stick with code samples that only require a standard 520ST.

 

 

Sorry, if you are going to list specific modes, A8 will win. A8 has a lot more graphics modes/text modes than ST. A8 can't do 640 modes but ST can't do most of the A8 modes of >16 colors. That's why you have to replicate pixels/lines to simulate those modes; otherwise I would have listed those modes as a separate advantage in my list. So Mr. Robot, Boulderdash, Joust, Pac-Man, etc. are 160*200 but the objects are well-defined at that resolution and full-screen.

Rubbish - ST wins because it has higher resolution, higher colour modes. ( and what A8 modes are >16 colours - nothing in any of the hardware manuals I've got? )

( I don't actually understand what your Mr Robot etc point is about though - can you clarify? )

 

ST has 512 colours, better than 128 for launch A8

Cut the "for launch" crap. ST not having RF modulator is worse than some 400/800 not having GTIA chips. 400/800 can pop in GTIA chip w/o soldering; you can't pop in a RF modulator in the ST. And I didn't put "lack of RF-modulator" in my list. Nor can you pop in a chip in the ST and give it more shades.

512 colours better than 128 has nothing to do with an RF modulator? - what is your point?

Even with GTIA - I can happily say pallette of 512 colours is better than pallette of 128 colours, as the only 16 shade modes aren't palletted.

 

RGB video is not better than A8. A8 was targetted for TVs so it doesn't need the RGB. ST needs the RGB video (making it more expensive) in order to show it's advantage of higher resolution.

Rubbish - RGB video is a better standard, ( and in Europe it was in a hell of a lot of TV's , with SCART/Peritel eventually standardising it )

 

So given A8s fast I/O using joystick I/O, that also has to be put into the comparison not just "oh, now we can use the parallel port."

Feel free to put abuse of joystick port as an A8 advantage - I won't argue with your opinion on that

[Crazyace]

If it's not S.Y.N.C. based, let's see it.

 

It's not dodgy; it works consistently. And the code above proves that the PRIOR 0 mode is DEFAULT. I didn't have to alter the PRIOR register to get the ORing to take place as the default setting of location 623 is 0. If it were dodgy, you would think the OS would have put some other value than 0 into 623 at startup. I have read other things regarding SYNC (for ST, CGA, and other machines) and CGA was an example which modified the frequencies of monitor to get new graphics/text modes (or mixed versions) that led to the damages of many monitors.

 

What is S.Y.N.C ? I've heard of sync scrolling ( short for synchronisation I guess) - but not S.Y.N.C

Please only concentrate on ST ( or A8 ) in this topic - you keep on bringing up CGA for some reason - maybe you're getting confused about something completely different on that card.

[Crazyace]

Technically obviously the ST is more superior, but I way way way prefer the 8-bit.

 

The OP is right, the ST just doesn't feel the same as the 8-bit at all, it really doesn't seem as though they are related to each other.

 

The ST just kinda feels souless in comparison to the 8-bit, like it's more like a traditional bland computer.

 

When I was young, I was sucked in by the flashy graphics of the ST, and sold my 8-bit to get one (I had in mind that I'd buy another 8-bit when I was able to).

 

About a week later I totally regretted it, the games on the ST just weren't as fun as the games on the 8-bit, they weren't even the same. In fact to this day there's not really many games that I like on the ST.

 

I've got games that I loved on both platforms - from Drol and Bandits on the A8 which hardly use any special h/w , Preppie and Rally Speedway , through Lemmings and Dungeon Keeper , Kick off ( and Sensible soccer ), Captain Blood and Another World

[PeteD]

 

If it's not S.Y.N.C. based, let's see it.

 

 

lol You've got a cheek. How many times have you spouted some theoretical stuff and been asked to prove it and declined?

 

 

 

 

Sorry, but PRIOR 0 is GTIA doing its normal operations and not a big discovery-- just type something like:

 

POKE 706,122:POKE 53263,255:POKE 53250,128

 

It has nothing to do with playing with video frequencies which has proven in history to cause problems/damage (i.e., CGA).

 

PRIOR 0 may be consistent but it's consistently almost impossible to use without extremely careful planning. It's certainly nowhere near as flexible in it's results as adding a bitplane on ST/Amiga where instead of ORing a PF and PM palette INDEX (to get another index which could just mean some random colour with an extra bitplane) you can take your pick and have full control.. double the colours, another X colours with 1/2 brightness for shadows or double brightness for translucency, etc

 

It's another case of a barely useful (note I didn't say useless)mode that's classed as being superior to other machines. I'd much rather use the PMGs as underlays to get colours I want in blocks up to their quad expanded size. It might be mono but at least it'll always be the right colour. PRIOR 0 seems like either an afterthought or something the designers realised they could do and just chucked it in there.

 

 

Pete

[PeteD]

Technically obviously the ST is more superior, but I way way way prefer the 8-bit.

 

The OP is right, the ST just doesn't feel the same as the 8-bit at all, it really doesn't seem as though they are related to each other.

 

The ST just kinda feels souless in comparison to the 8-bit, like it's more like a traditional bland computer.

 

When I was young, I was sucked in by the flashy graphics of the ST, and sold my 8-bit to get one (I had in mind that I'd buy another 8-bit when I was able to).

 

About a week later I totally regretted it, the games on the ST just weren't as fun as the games on the 8-bit, they weren't even the same. In fact to this day there's not really many games that I like on the ST.

 

To be honest I prefer the A8 to the ST as well but then I'm generally more into 8bit stuff. The A8 was some pretty good kit for it's time whereas the ST was kind of a box of bits they found and stuck together. It's certainly not a quantum leap but then I suppose it should've been the Amiga..

 

Having said that I'll still defend the ST's "capabilities" and it did have some pretty impressive games/demos that blow the A8 out of the water, as they should for a newer machine.

 

 

 

Pete

[drac030]

ST has also the DMA port, which however does not look so universal as the XL/XE PBI/ECI connector: I don't think that using the DMA port you can add autobootable devices to the ST system (autobootable: i.e. the OS does not contain predefined routines to boot them), and this PBI/ECI does allow.

 

I'm a bit confused about this... I mean, my Mega ST boots off a 4 gig SCSI drive. My STacy boots off a 2 gig SD card... I'm not sure what you are trying to say here. Clarify? Thanks!

 

BTW, hadn't seen it mentioned - can the 8bits use CDROMs? I mean as in burn them, make audio CD's all that stuff. Thanks again.

 

I wrote what's my point in the paragraph you haven't quoted. In the part quoted I even explain what I mean by "autobootable", but still you seem to have confused it with "bootable". I admit that this might have been obscure, so: bootable = booted by routines predefined in the OS, autobootable = booted by own routines, added externally to the OS at power-up via some sort of predefined expansion mechanism. You may also want to know that I myself owned a Falcon030 for about 14 years and coded something on it in assembly and C, so I basically know, how the ST system works (even internally).

 

Ok, to clarify (separate points for convenience and clarity):

 

1. The point is better universality of the XL/XE expansion bus over ST DMA Port.

 

2. ST boots off a harddisk? Sure, because BIOS contains predefined routines to boot off a harddisk (XL/XE doesn't, yet it boots off a harddisk!).

 

3. But, can you use the DMA port to connect to the ST an automatically initializing (= autobooting) device, for which the ST BIOS does not contain predefined routines? An IDE drive, for example? Not unless your controller is a separate computer which emulates SCSI commands which BIOS issues to the DMA port. More generally: the external device must conform to the behaviour expected by the BIOS, and you can't modify the BIOS' behaviour without modifying the TOS ROMs. At the other hand, on XL/XE this is not an issue, because it is the device itself which defines routines to handle itself, and the XL/XE "BIOS" works at the abstraction level that makes it (the "BIOS") hardware-independent. You can connect anything without a need to emulate anything.

 

4. Another example: can you attach a graphics card via the port and hope that the BIOS will initialize it so that you don't need to load a driver from the AUTO? So that you wouldn't wait looking at blank screen until the driver loads? I guess you can't. There is no mechanism on the ST that would allow you to attach plug-and-play cards without hacks (like these on the cart port). Yet on XL/XE it is possible to initialize an external device so that it becomes a part of the system BEFORE it goes to boot disks, or even to open the screen console.

 

Conclusion (not to be taken separately from the rest of the post): XL/XE is a more open architecture than ST, both hardware-wise (connectors) and, even more, software-wise (plug-and-play mechanism, known as Parallel Bus Interface, absent in ST). So in this point XL/XE seems better than ST, eventhough it is older and therefore inferior in gfx and processing power.

[Heaven/TQA]

never thought that the ST is superior to be honest... in terms of flexibility of the hardware (gfx chip, sound f.e.)... ok... games were good but as coder when I touched the machine (but never cought my attention too much)...

 

where is my display list?

 

512 pallette vs 256?

 

3 channel yamaha vs 4 channel pokey?

 

shifter? no...thanks...

 

bitplanes? no...thanks...

 

so actually what made me using my 1040ste plus harddisc for many years were the 640x400, my hard disc (and I needed an extra hardware fix for 50 EUR because of hardware bug of the ACSI chip (?))...

 

btw... just repacked my 1040 and found the hard disc (i guess 20mb) so actually... if the beast boots again... I could in theory rescue source codes...

[Crazyace]

...

Conclusion (not to be taken separately from the rest of the post): XL/XE is a more open architecture than ST, both hardware-wise (connectors) and, even more, software-wise (plug-and-play mechanism, known as Parallel Bus Interface, absent in ST). So in this point XL/XE seems better than ST, eventhough it is older and therefore inferior in gfx and processing power.

 

The 400 and 800 didn't have this capability though? ( and I guess you could implement a rom device on the ST via the cartridge port if you wanted ) so I expect what you're comparing is the XL PBI to something like the internal bus connector in the Mega ST machines?

It's definitely more flexible than the DMA interface though.

[Crazyace]

never thought that the ST is superior to be honest... in terms of flexibility of the hardware (gfx chip, sound f.e.)... ok... games were good but as coder when I touched the machine (but never cought my attention too much)...

 

The Amiga had all of the cool hardware - I think I felt a bit more warmly about the ST than you, as I'd just been programming for the QL ( which was pretty slow - but at least had a nibble screen mode.

( Also the Amiga 1000 was way way more expensive than an ST )

[drac030]

I am comparing to 520ST and 1040ST. I don't doubt that ST-line, since MegaST (1987?) eventually caught up at this point. Megabus is probably more universal than PBI, but it appeared only[1] 5 years after PBI was invented. Still, they had a problem with standardisation: MegaST has megabus, MSTE/TT have VME (different than megabus), Falcon has internal expansion port (different than megabus and VME, eventhough releasing the TT Atari promised all future computers would have VME).

 

That's true that PBI vs CART/ECI are two different connectors, but the interface itself it the same and you can turn one into another with a simple adapter (most of the time, as CART/ECI is a development of PBI). Even Falcon had nothing similar to the standardised XL/XE plug-and-play mechanism.

 

EDIT: no, 800 doesn't have it, 800 has internal slots, though, which ST doesn't have either.

 

[1] pun intended

Edited December 28, 2009 by drac030

[Crazyace]

Having a full system bus connector ( or even r/w ) on the cart would have been great - I don't know why Atari didn't - maybe the idea was that all of the interfaces were already present on the machine. It was annoying having to 'spoof' the write for Replay.

Did the PBI give you dma access though? ( like the Commodore REU's did )

[+poobah]

USB sticks have to be used through some device driver due to nonstandard means of accessing the USB sticks.

 

USB protocol also is serial so not as fast/efficient as a parallel port or A8 joystick port.

 

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

 

That's strike two, poobah. Initially you argued STs joystick ports aren't slow and now this.

Resorting to outright lies now?

 

I said they were more than fast enough to do the job they were designed for, and that other ports on the ST were more appropriate for high speed tasks.

 

If I do a LDA 54016 on A8, the equivalent on PC w/USB HID would require a series of I/O instructions and no guarantee of the exact time of arrival of information. Suffice to say that HIDs use a slower protocol and you'll end up using up more time than the LDA 54016 (2 microseconds) or parallel port which is a simple IN AL,DX. Now, don't argue that speed is useless for joysticks because you would rather have a faster way of reading it and thus give more time for other things.

 

How do you babble about "nonstandard means of accessing the USB sticks" and then mention HIDs? Either it is standard or it isn't. (Hint: it is)

 

Do you really think you know more about this stuff than the rest of us? (hint #2, you don't)

 

Your 2 microsecond time is also wrong.

POKEY & the PIA don't instantly latch stick & button presses to the memory mapped registers.

Oh wait, you also conveniently left out the triggers, would it be because you need 4 more reads to get them?

 

Your half-truths and narrowly crafted measurement criteria are laughable.

 

{snipped comment about your actions here vs. your web-page, I didn't want to get personal, but it was tempting}

Edited December 28, 2009 by poobah