Rybags

I (regret now) sold practically all my old 3.5" Amiga floppies. So my personal stocks of 3.5 vs 5 is probably in the order of 1 to 3 (not counting ED ones with the 2 holes since they're practically useless when formatted for 720K) In terms of reliability I'd probably rate the 5" as better despite mostly being older. I'd put that down partially due to the fact that they're hardly being asked to do much when formatted to around half their rated capacity. My oldest 5" is probably from around 1982-3 and I'd have plenty from 1984-7. Probably very few after 1989. I don't think anyone makes either type anymore? Sort of sad. NOS has it's attractions but would be a lottery. I've seen 3.5" 10 packs a couple of times in op shops over the last year but they're the ED ones so not really interested.

It's packed away but I'll try and see about getting it out in the coming days... and it's got a Supermon OS board which has stability issues also.

Could this be related to chip age, or maybe the amount of time the chip has been in use? My Atari 400 here - it's barely been powered on probably since the early 1990s, so might serve as a good test case for a low use GTIA - though in the period 1981-85 it would have had a lot of use.

A worthwhile project to catalog such titles but I'd suggest to expand it to include other special modes and expoits like PAL blending (APAC, TIP etc) and maybe 480i interlace (Stellar Shuttle 480i I think is the only one there) Also worth mentioning games that are switchable or also have multicolour versions (e.g. Drol)

I doubt the mains would even know about it. You'd probably not get a short if components blew out and if you did it'd be likely that fine tracks would be the weak point that'd melt and go open circuit. But as for ICs... I don't think many would well tolerate running with current in the wrong direction. It would be interesting though to know what survives and what doesn't in this case.

I've not done such programming. Though the logic involved in the Atari memory selection at that level is usually fairly simple. But I don't know if there's specific stuff for the 1450 - entirely possible since there's sufficient differences among the likes of 800XL, 1200XL, XEGS.

There's some not so well documented features among the MMUs. From memory, on an XEGS Basic will always override the game portion if enabled (there being 4 possibilities there) And not totally sure if the OS has to be present for the Self Test to also appear (all machines)

Roms don't use Ras/Cas. But Freddie should make a system a bunch more reliable as the timing is precise based on 14 MHz clock increments and the delay line relies on electrical characteristics to get it's fractional values. But 1450... doesn't that have the voice chip and extra Rom to drive it? Could it be that some Rom overlay is going on which gives a different checksum?

2 failed OS Rom chips with the same symptoms seems unlikely... more likely is there's some issue with the MMU or something in the memory selection circuit like 74LS chip or PIA.

I doubt it'd be practical to run one from the Atari - likely the mathematical operations would take thousands of times longer and you'd be constantly waiting for calculations to finish with the printer sitting idle.

Given it's just a Rom and not a processor, stress test in my book would mean doing lots of memory accesses to it. You could point the character set to $D800 which would mean plenty of accesses taking place. Put some random characters onscreen then observe if any graphical glitching occurs.

It's just a 2K ROM - so it'll either work or not. If your existing one was faulty you'd likely know it by now although non-Basic games in general don't tend to use the FP routines. A bunch of Basic games would probably be sufficient to test it out. Go for ones that have no or little usage of assembly routines. There's various SysInfo type programs around - not sure which if any will checksum and identify it as a Fastchip. But if you have means to get downloaded files onto your Atari it'd be an easy task to load the 2K image into Ram then compare it to what you have.

I'm fairly sure they should work fine on a 48K Ram older system, just make sure no cartridge is present and use a compatible Dos or menu loader. Stephen's IK+ pic worked fine on an emulated machine for me...Stephen_IK.xex

Thanks, downloaded for later - 99 Meg.

Normally if a video is taken down due to (c) then I'm fairly sure it becomes unavailable for everyone including the uploader. Possibly you could host it somewhere - like Google Drive then get a share link?

That video is blocked, tried again with Opera VPN for the same result.

IRQs can be concurrent and it's up to the interrupt handler to prioritize and execute them in order. By setting a bit to zero in IRQEN that clears the particular IRQ, then you store the shadow value which potentially reenables it. If you just processed the IRQ without doing that it'd keep triggering the same one.

U1Meg from memory can be done without modifying the machine. VBXE is intrusive though the worst thing is cuting a hole if you do so to put the video jack in. A reasonable alternate to VBXE of course now is Sophia (or in fact you could run both) but you'll still need to run the video out, and you miss out on the extra features/software.

Yep, RC will tend to generate 75 bytes or more for every scanline in the picture you put into it. About 41 bytes for the bitmap+Display List entry then more again for the programatic register changes. Compression could help out but of course that's of little use if there's not enough Ram to depack into.

The main part I would assume just has stock OS calls. But DDT uses a custom narrow mode window and probably does direct screen writes etc which makes it more machine specific. Then there's the bankswitching. Entirely possible DDT executes all from one bank (wasn't it initially a total seperate product? ) Source code - do we even have that? Target machine - chances are it'll have a less sophisticated OS and you'll need to supply what otherwise existed thanks to CIO and other subsystems.

Lots of different models, but a quick search finds more than one very close match, e.g.

The thought I had was take an existing image and manipulate it. I don't think I've played the game so know little about it, but here's an example pic.

With 6K spare you could add a title pic or something... maybe even RastaConverter.

That looks like a crash, typical of a corrupt display list when a program plays up. That aside, the colour trimmer just changes the spread of the phase offsets and I don't think it ever causes a colour to revert to monochrome (?) The problem with RF aside from the poorest video quality is that the port itself is made from rubbish mild steel that easily oxidizes and gives poor conductivity, not to mention the physial design isn't much good either. Whenever possible it's a good idea to use composite video at the least.

PIA also handles /Command but it's not timing critical to the point where several cycles lag in state change would make a difference.