Jump to content

ijor

Members
  • Content Count

    2,666
  • Joined

  • Days Won

    2

Everything posted by ijor

  1. For the Happy 1050, yes.
  2. Well, probably all of them, not just many. But the rom is still banked one way or the other. I think Larry's point was about a custom modified firmware that runs on a flat linear 8K address space and doesn't require banking at all.
  3. I never heard and not sure it would make much sense. As you are saying, it wouldn't be compatible with Happy software. So it wouldn't be really a Happy clone anymore. Of course, there were clones for other enhancements similar to the Happy, like the Duplicator, that don't use a banked rom.
  4. The Happy, as most of these drive enhancements, is a programmable drive. It can run uploaded user code.
  5. Strange they used a CMOS cpu for a Happy clone. May be they used simply what they had at hand. But a couple of titles will break. Also the Happy 1050 software doesn't have a feature to use a slower RPM. Strange.
  6. According to a user on atari-forum, he was victim of a scam and lost $560 for an Atari item that paid but never received. I though I should post a link to the relevant thread, just in case: https://www.atari-forum.com/viewtopic.php?f=29&t=41004
  7. There were definitely 5.25 drives produced for the ST. I still have one. Yes, most of them required a slower step rate and they included a bootable disk to change the default step rate. So yes, it was limited in some ways. But it was very useful for accessing older PC disks and then 5.25 drives were somewhat popular for PC emulators. The problem with some 5.25 drives that require high current drivers, which could damage the PSG, only applies to generic drives not specifically designed for the ST. ST drives either used a mechanism that was compatible, or included a small board to buffer the signals inside the drive box. You can actually see a picture of an 5.25 ST drive in this very same thread. Or may be you mean something else and I am misunderstanding?
  8. Well, I'm not going to argue with that because I'm definitely not an expert on fast graphic routines. That's why I used the term "consensus", and not a personal statement. But then, why most demos do not use Blitter? Not only that, when you ask them about the Blitter, they claim it is not very efficient. Again, hence the term consensus. I remember Leonard, with all the demos he coded, talking about that. May be he was wrong, I don't know.
  9. The flux level devices, like Kryoflux, Greaseweazle and SCP, can definitely image copy protected disks. But if they are original disks, or even copies of original disks, chances are that these games were already dumped and images are already available online. Not sure it is worth to invest too much money unless you happen to have a very rare title. I would go with some of the cheaper Greaseweazle variants. Be aware that after so much time, many disks become unreadable because of different reasons.
  10. The general consensus is that the Blitter is not very efficient for many operations because of the heavy overhead required. It still can be much faster than the CPU when real time shifting is required, but games and demos can typically use pre shifting. The Blitter can also be very fast for such things as 3D transformations if blitting can be overlapped with CPU computation. Blitter DMA prevents the CPU from performing external accesses, but the CPU can still internally perform divisions and multiplications. This requires some clever and accurate coding to actually take advantage of this. Yes, but this is mostly because TOS code is not very efficient. Some third party VDI and LINE-A replacements can perform as fast as Blitter, or even faster, using pure software.
  11. Pokey internal simulation waveform that shows the relation between STIMER, the audio logic and IRQ output. Timer 1 is configured as 8-bit, pure tone, divisor zero and clocked by the 1.79 MHz clock. Most signals use the same name as in the schematics published in this thread. cycleCtr is a virtual cycle counter that doesn't exist at the hardware ChannOut1 signal is the digital output of channel 1. It is the input to the channe'sl DAC. The first cursor is right after the CPU write cycle to STIMER. The second cursor at the right marks the active edge of the external IRQ signal. Let me know if you would like to see other signals included, or if you need a different simulation.
  12. I'll look at this in more detail shortly, and I will also post a waveform simulation. But, if I understand correctly what you are saying, note that there is a cycle delay missing here. STIMER RS-latch is set one cycle later. The address decoder (Addr9w signal, in this particular case) is asserted at the next cycle after the CPU write cycle.
  13. It is not a firmware crash that persists power cycles. It's a failed power up that doesn't boot correctly. It happens with most original Happy 1050 boards from time to time. And when it happens it tends to happen a couple or more times in a row. I am curious exactly why. At one point I speculated that the ROM could power up in the "wrong" bank. But the ROM code seems to be ready to power up in either bank, at least in theory. It should be possible to trace the bus activity with a LA and see what's going on. But I was always a bit lazy to perform the test, especially considering that one might be too "lucky" and perform several power cycles with the instrument attached but always booting correctly. You power up the 1050, but nothing happens. Power led turns on, but otherwise everything is dead. Of course it doesn't happen very often. Anybody with a non original Happy, Atarimax or whatever, experienced the same issue?
  14. Hi Phaeron, I'm currently on a trip. I won't be able to look into this until next weekend, in ten days or so. Please bear with me, sorry.
  15. Yep, that should work fine without doing anything special. Are you sure about that? That is not how a normal Gotek behaves. Note that when a single drive is detected the operating system will use the single drive both as A: and B: for copying purposes. But this is just a high level logical mapping performed by the OS, and should get away as long as two physical drives are detected. Also note that you must boot with both drives turned on because drive detection is performed at boot time only. You don't need to insert a disk in the second drive at boot time, but it must be connected and turned on or it won't be detected.
  16. It does, of course, both in reads and in writes. See Pokey internal schematics page 1; follow signals PreS01 and Phi2B. But even without looking at Pokey's internal design, the 6502 bus interface is synchronous. Address bus must be latched at one phase of the clock and the data bus at the other phase.
  17. I think you don't understand the point. Or might be I didn't expressed myself correctly. There is no compatibility issue here by inverting, or by not inverting, the data. We are talking about data written during format time only, not about how data is written normally with a write sector command. You could write $E5 to the disk surface, which could then read as $1A. Or you can do as this firmware does, write $1A to the disk surface that the computer reads as $E5. Either way it wouldn't be fully compatible with the 810 because the 810 "blanks" sectors at format time by writing $FF to the disk surface. So it is not that they inverted the $E5 for compatibility with the 810, because writing $1A to the disk surface doesn't make it more compatible with the 810 in anyway. My reasoning that this could be a bug, is because if you want to follow the theory I described in my previous message, then you want to write the $E5 value to the disk surface. What matter here, for this purpose, is what you write to the disk surface, not what the computer reads. So if that was indeed the purpose of writing $E5, then by writing $1A to the disks surface instead, they committed a bug. But I don't know, may be he idea of filling the sector with $E5 at format time was just to imitate what other platforms performed. Not sure that would make much sense, but who knows.
  18. Most Atari drives fill all sectors with zero when formatting the disk. That's what the 810 originally does, and most other drive follow for compatibility reasons. The actual pattern written in the disk surface is $FF because the sector data is written inverted. But technically, using $00 or $FF is not the best value to be written at format time. If you check a PC disk you will note that empty sectors are usually filled with $E5. This is because research have determined that the MFM pattern produced by writing $E5 is magnetically the most stressing pattern to the disk surface, certainly more than writing a plain $00 (or $FF). The idea is that when you format a disk, you want to test it with the "hardest" magnetic pattern. If it verifies OK when the sector is filled with $E5, then it should work with any other pattern. Or at least that is the theory. 1050 rom Rev E, at least the one Nezgar posted above, follows in some sense the concept, and fills sectors with $E5 when formatting the disk. But the strange thing is that, because the data is written inverted, the actual sector written on the disk surface is $1A, and not $E5. I guess this was a bug, let alone that the whole concept applies to MFM only, not to single density. I also assume that eventually they realized the incompatibility with the 810 and later rom revisions fill sectors with $00, writing the $FF pattern to the disk surface.
  19. In the exact example you describe, the Megafile being first in the chain, then yes, absolutely it must be turned on. And this is for the simple reason that the Megafile 60 pass through connection is actively buffered, it is not passive (as is i.e., on most Atari 8-bit SIO devices). Some signals will simply not reach the second hard disk if the Megafile is turned off. But there is no universal answer to the question as stated at the thread title. It depends on the specific host adapters. Some use a passive pass through connection, some ICD adapters are allegledly "smart" with logic that adapts depending on the other devices.
  20. Hope everything is recovered. Do you (or anyone else) have any idea about the chip photoplots? He claimed at some point he acquired a collection of photoplots for almost every single Atari custom chip. Invaluable material, hope it is not lost.
  21. Since you are using the cart code, please include the name of the one that made the port from the original Disk version. I understand it was quite some work because, IIRC, he didn't receive the original source code. He doesn't deserve the name to be removed from the title screen. Otherwise, great work. I loved this game!
  22. Would you mind taking a couple of pictures of the interface board and how the switch is connected? Should have more logic than a "simple" ST drive without a 40/80 switch.
  23. I've never seen an ST drive with a 40/80 tracks switch. Would you mind opening the drive and take some pics? I would assume it has some logic to enable or disable double step. Would be interesting to see how this is implemented. There were several 5.25 drives for the ST. I remember I.B. and Cumana.
  24. You can use replacement parts that are compatible and, apparently, they seem to be available. They have the same pinout but more resources, what Altera/Intel calls vertical migration. They would be more expensive and you would need to recompile the core to the new part, though.
  25. If you want an answer, then post a proper, polite question, instead of a so negative statement. For starters, there is no much design in the GOEX beyond the physical and mechanical adaptation. The software and firmware are generic for the Gotek, not specific for the Goex. The GOEX uses Flashfloppy firmware and, depending on the version, some HxC software. So if you have issues with the software, in first place check the Flashfloppy wiki and the HxC documentation.
×
×
  • Create New...