mizapf

Just finished rewriting the Horizon, it compiles again, but I'll need to do some debugging... tomorrow. The full rewrite was not necessary, but this was the opportunity.

Is the optional 32k RAM also battery-backed? It is not really clear from the schematics.

With TIImageTool: java -classpath tiimagetool.jar de.mizapf.timt.CommandShell type mydisk.dsk FILEONDISK

Fred uses frames, but you can certainly "unframe" the contents (right-click ...).

I would suggest not to call this an acknowledgement. This is done by the operation at 0A84 (MOVB @>FC00(R15),@>837B), since it actually clears the interrupt. According to the specs, doing a SBO on the interrupt inputs of the 9901 arms the interrupt trigger. Since this is after LIMI 0, nothing happens (all interrupts from the 9901 are on level 1). This SBO seems to be done in preparation of the later return from the interrupt service. The comments on SBO/Z >0002 in "TI Intern" are consistently wrong, as I found out (said the one complaining about the thousands of wrong-way drivers on the road... 🙂 ).

Ah, the Horizon 3000 manual talks about a "piggy-back board" when you wanted to go above 1.5 MiB. Also, it seems as if the Horizon 2000 and 3000 could have stacks of up to 3 chips. Since all chips were SRAM, it suffices to connect them by a single separate wire (pin 20), and apart from that, solder all pins together.

Maybe, but I'd like to watch it. You look at a curve and start pondering what kind of filter it could like.

But the schematics that I found for the 2000 and 3000 show 32 RAM chips, just like the 4000 type. Or were those 2000 cards not fully populated?

Successfully loaded the created WAV file for Adventureland in MAME. 🙂 I ran it through Audacity, filtering away some higher frequencies, and pushing up the amplification. May I upload those files on WHTech?

Hmmm, OK, will try whether MAME accepts them, but I'll have to convert them to WAV, because MP3 is not supported. (Hence my question about original WAV files.)

Does this work with MP3? I always thought MP3 would modify sound data in a way that you cannot hear, but it does change them, so it might not be suitable for digital data. This is how the wave form looks like. Do you have them as WAV as well?

OK, this means I can offer an option for the RAM type (128Kx8 / 512Kx8) and a number of RAM circuits from 1 to 32, with the assumption that the numbers 1-16 fill up the circuits in the bottom layer contiguously, then 17-32 continue on the top layer. Maybe it would suffice to offer 0 / 8 / 16 / 24 / 32 chips as options to cover all interesting cases. The types 4000 vs. 4000B would then imply to have a 8K vs. 32K DSR chip with the appropriate decoding. From the schematics I did not quite understand the idea of the second LED in the middle of the board. If feasible, I'd like to add the types 2000 and 3000 as well. If this turns out to complicate things too much, I'd have to define them as a distinct card.

I'm currently reworking the Horizon emulation in MAME. Some questions: I saw that you can put two different kinds of memory chips on the board (128Kx8 and 512Kx8). Also, you can put a maximum of 32 chips on the board (stacked in two layers). Chips must not be mixed; what else has to be considered? - Does the bottom layer have to be completely filled? - The top layer seems optional. Can you fill it partly? - Can you fill each layer partly? If layers have to be filled, you'd only have options for 16 or 32 chips. If only the bottom layer must be filled, you'd have min 16, max 32 chips. If the bottom layer need not be filled, you could have 1-32 chips, where the first 16 chips belong to the bottom layer (unless both layers could be partly filled). I recently posted some more questions: 1. The only difference between HRD4000 and HRD4000B is the switchable DSR bank, right? (CRU bit 14) 2. How do HRD3000 and HRD3000B differ? 3. Is the HRD4000(B) the only HRD that decodes AMA/B/C? 4. Is "HRD2000" = "HRD+ Series 2000?" 5. Is there any further difference between HRD+ and HRD2000 besides the stacking of control chips?

If you have a writable cartridge that allows configuring with an auto-start, maybe you can set up a program for the cartridge to dump the ROM and the scratch pad to some RAM area to investigate further. The cartridge ROM will be executed early enough so that one might see something interesting.

Just checked: When I create a new file (e.g. open a new file in QDE and save it) in native mode, the FIB contains the "FI" signature (on emulation and on the real system). This is also true when you create a file in GPL mode. However, when I use "copy" in GeneveOS to copy that very file, the copy lacks "FI". [Edit: Real system with ASCSI card, emulation with HFDC]

I used the area below 8300 in the Geneve's GPL mode for my Guru meditation program:

The easiest way is to run MAME, write some files, and then use TIImageTool and use "View file information block" in the context menu (right-click on a file). Since MAME uses the original HFDC DSR, any real issue should also show up in emulation. (And the advantage is that we're doing regular backups of our image files, right? 🙂 Wait, while I'm talking about that, I think I should do a new backup.) I just created a file in GeneveOS (MDOS) and found the FI signature. However, I also see files which don't have it. I can do a check on my real Geneve with the SCSI system to check whether these files come from the SCSI system.

Wait, I'm going to cast a time-reversed spell to discourage them from using that Z80 ... done. 🙂

Also, do we have better schematics than these hand-drawn ones of the HRD4000 (from the "Construction Guide")?

I saw the manual is about the HRD4000B. So this is yet a newer version of the HRD. I'll see how I can pack all variants into the emulation, including the HRD2000. Right now it is only the 4000. Some questions: 1. The only difference between HRD4000 and HRD4000B is the switchable DSR bank, right? (CRU bit 14) 2. How do HRD3000 and HRD3000B differ? 3. Is the HRD4000(B) the only HRD that decodes AMA/B/C? 4. Is "HRD2000" = "HRD+ Series 2000?" 5. Is there any further difference between HRD+ and HRD2000 besides the stacking of control chips?

Just to give a short idea why the SID Master broke the Horizon in MAME: The SID Master requires me to propagate all CRU accesses to the P-Box, unlike all other cards, because it deactivates itself when an access to CRU 1xxx is done. In particular, when the 9901 in the console is accessed, the SID Master is activated again. I let the access be consumed by the 9901, so it was not visible in the box, so I changed it, believing that no PEB card would be bothered (because I have to check the CRU address anyway). However, there was a glitch in the Horizon card: When Phoenix was turned off, I set its CRU address to 0000. And to check whether some card is accessed, I'm doing a test like "if ((address & 0xff00)==myaddress)". You see what happened...

Yes, that was in fact my major point (checkboxes), I just saw that my post looks as if I only commented on the radio buttons on the top.

I think I finally got the answer I was looking for. Have a look at the checkboxes. This applies to everyone using FileZilla on every operating system: Make sure you set it to binary transfer! I found some comments on that in a forum. The reason for this setting is that people using FileZilla on Windows, pulling files like README from a FTP server, will have trouble reading them with notepad.exe when they were transferred in binary mode. Since most TIFILES files stored on WHTech do not have an extension, FileZilla will break them: Linux users get 0D deleted from 0D0A, while Windows users may find 0D inserted for every 0A in the file.

Yes. If you use a Horizon, please stay with the 0.224 release. Sorry for the inconvenience. It should be fixed with the next release by the end of November (0.227). And an appeal to all MAME users: If you spot a regression (something stopped working from one release to the next), please inform me as soon as possible so that the error can be fixed by the next release.

This is really interesting: $ od -An -tx1 -w1 -v 4thdoca.bin > doca.txt $ od -An -tx1 -w1 -v 4thdoca_broken.bin > docb.txt $ diff doca.txt docb.txt 19466d19465 < 0d 34037d34035 < 0d 107297d107294 < 0d 135306d135302 < 0d 146569d146564 < 0d 149305d149299 < 0d 186603d186596 < 0d 196223d196215 < 0d (first line: create a hexdump of the 4thdoca.bin file (which is 4THDOC1A of today) with single byte output per line; second: create a hexdump of 4thdocs_broken.bin (which is 4THDOC1A of yesterday); third: compare both hexdumps) The diff output indicates that the first file has some more bytes at the intervals xdx (line 19466-19466 etc.). So the result is that yesterday's version is missing some 0d bytes. Looking into the file reveals that these are the 0d bytes that are followed by 0a. So the download converted 0d-0a (DOS/Win) sequences to 0a (Unix) sequences. This is normally an indication of the wrong FTP mode ("ascii" vs. "binary"). I thought I downloaded the files with Firefox; I also worked with FileZilla that day. I retried it right now, and again, the files were transferred in ascii mode. It seems as if the "auto" mode of FileZilla took the wrong decision. When I set it to "binary", everything is OK. This is really unsettling. How many transfers have failed in the past?