mizapf

Thanks! That looks very helpful indeed. And a relief to my eyes, not forcing them to decipher badly photocopied text.

This is oddly hurting my feelings...

I'll try on my real Geneve. Sometimes I suspect that there are different versions of files by the same name - maybe changed by exports and imports. Edit: Tell you what - I cannot reproduce the problems today that I had yesterday. I downloaded the files from WHtech once more, and they differ. Starting at position 19338, a byte is missing in the downloaded file. At 33909, the next byte is dropped. This continues until 8 bytes are missing at the end, padded with zeros. I have no clue what happened to the file - a problem in the WHTech server, in the Firefox downloader? Or in my TIImageTool importer? So it does not make sense to look further. We should have more checksums in our files. (That's what I wanted to say - we ultimately trust the downloads, imports, and exports. If there are unknown glitches, we'll get into trouble some day.)

Confirmed. In fact, it was my fault after all, but it happened when I added the SID master, without doing anything with the Horizon. Sometimes there are funny coincidences, like here, which have a totally unexpected result. It's been quite a while that I learned about the Horizon. Before I go through all docs again: - In the HRD4000 manual, the CRU addresses are listed differently than in earlier releases (2000, 3000). What is the difference between "1400" (switch 5) and "1400 Phoenix #1" (switch 2)? (same with 1600) - J4 is used for single or dual ramdisk configuration, as I understood. Page 2 mentions that as the Phoenix mod, but what does it mean for the TI mode? - I am a bit confused about how many CRU bases are used for the dual ramdisk. I read that the Phoenix mod uses two ramdisks on the same base, but what about the TI mode? - The ROS manual does not mention the Phoenix mod at all. Is it still there?

Most part of it is a cassette adapter (to allow using a cassette recorder with the SGCPU).

TNLX 06BHT [email protected] BNLPTTDR These characters all have even ASCII code. Add a 1 to some of them: TOMY 16BIT GRAPHIC COMPUTER (i.e. the rightmost data bit is stuck to 0)

I once proposed some more names like "GenOS" or "GeneOS", but we kept "GeneveOS". 🙂

I've been searching for the bug for some hours now ... with no success so far. The problem is that the LZW decoder gets a key that is nonsense: The lookup table contains 2571 entries at some point of time, and that key number is 3385. It may request a key 2572, which is then created, but 3385 is clearly wrong. After that, things take a dive downward, more invalid keys, and finally the table gets an overflow. So the table was not too small, it was the data that broke the decoding, as it seems. As you said that you were able to read it in TIDIR, I started Archiver4 in GeneveOS (by EXEC13) and tried to unpack the archive. Yes ... and Archiver locks up right at the file FORTH_04 where TIImageTool got into trouble. I also tried Archiver III ... with the same result. Try to unpack FORTH_04 on your Geneve or TI. Something is wrong with these archives, I am quite sure.

Who else has an operating system with two names? 🙂 I'm really torn between GeneveOS and MDOS. I think that "GeneveOS" deserves a chance ... but "MDOS" obviously still sounds more catchy in many people's ears. I have some sympathies with GeneveOS, in fact. As you once said, MDOS is a bit dated, referring to the origins at Myarc.

I tried it, and it seems to work (in dosbox). This is the output of JED2EQN for the RS232 PAL: ; JED2EQN -- JEDEC file to Boolean Equations disassembler (Version V063) ; Copyright (c) National Semiconductor Corporation 1990-1993 ; Disassembled from rs232.jed. Date: 10-27-120 chip rs232 PAL12L6 i1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 i11=11 i12=12 o13=13 o14=14 o15=15 o16=16 o17=17 o18=18 i19=19 VCC=20 equations /o18 = /i2 * /i3 * /i19 * i4 * /i5 * /i6 * i7 * i8 * i12 * /i9 * i11 /o17 = /i2 * /i3 * /i19 * i4 * /i5 * /i6 * i7 * /i8 * i12 * i9 * i11 /o16 = /i2 * /i3 * /i19 * i4 * /i5 * /i6 * i7 * /i8 * i12 * /i9 * i11 /o15 = /i2 * i1 * i3 * i4 * i12 * /i11 /o14 = /i2 * i1 * i3 * i12 * /i11 /o13 = /i2 * i1 * i3 * /i4 * i12 * /i11

Sigh ... there seems to be a bug in my LZW.uncompress() method, but I have to dig deeper (and to learn again how LZW works...). It seems as if the uncompressor detects a "termination code" although the bitstream is far from being empty.

I did not change anything in the Horizon emulation. But I noticed that there was a commit "Got rid of global_alloc/global_free", not applied by me but by another dev. What problems did you have? If this is a regression I have to fix it.

MAME 0.226 has been uploaded to WHTech already. 🙂

Dual, quad, or hexacore is not relevant for MAME, since it only runs on a single core at a time. Unless you get stuttered sound output, no problems. Still, I'd only use debug in cases where I need it.

I cannot unpack these archives correctly, at least by my TIImageTool. Could be that the failure is on my side, of course. 4THDOC1A is broken, 4THDOC1B allows unpacking, but some files are broken, and same for 4THPGM10. Do you have unpacked versions? Side note: I uploaded the GenASM docs to the Geneve.new folder. [Edit: I do have a bug in TIMT; the archive table got an overflow when I tried to open 4THDOC1A. Still, most of the files don't open. I'll check.]

It could be interesting to calculate the shortest possible transfer time. To consider: Time between a sector and the next sector, head step time, rotational period 200ms, etc. The HFDC reads sectors directly into its on-board memory, but you have to download the sector contents from the card later; the WD cards cannot buffer sector contents.

Yes, but it slightly slows down the emulation.

I'll do, and I'll put them in the new subtree Geneve.new.

Maybe it would not have been created.

"Ramdisk speed"? There is at least an upper bound to the data rate: 125 kbit/s (single density) and 250 kbit/s (double density). It won't get faster from a floppy for sure.

Why debug? Do you start with "-debug" (or "-oslog")? If you don't need it you should turn it off.

I just remembered that I uploaded a ready-to-use HD image to Whtech, so no need for setting it up. Just in case someone wonders how to get to a bootable HD.

This is my Geneve launch script: #!/bin/bash ./mame64 geneve -peb:slot5 speech -peb:slot6 tirs232 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 /home/michael/mame /disks/hd/mainhd.hd $* You can create a bootable hard disk with my TIImageTool. It comes with GeneveOS 6.50. File->New hard disk image; keep the sectors per track on 32; you can increase the heads up to 16 and the cylinders up to 2048; but maybe it is just sufficient to go up to around 100 MiB. 1984/16/32 delivers 248 MiB, the absolute maximum size (the file system does not support a larger disk). Then: Utility->Install GeneveOS

I don't have any experience with MacOS, although it is a Unix-like system. Does it use the bash? In that case, the Linux scripts should work, possibly after adapting the paths. Maybe @Shift838 can give some more information.

No. COUNT is the address of the location where you store the count, not the count itself. This is a typical issue with assembly language that you have to be aware of. You have to work with addresses and with values, and there is no data type to tell them apart. Also, COUNT seems to refer to a byte address. Hence, you have to use MOVB to get it and then shift it into the low byte. MOVB @COUNT,R2 SRL R2,8 AI R2,10