mizapf

Ah, at least I see a crash on QUIT (illegal opcode).

I just noticed that I have had Robotron on my todo list for a decade by now, as it was not running stable in MAME. I remember that I already found out that it was related to a glitchy interrupt handling, which would have meant that it was a bug in Robotron - although people assured that they did not observe that in real hardware. So I gave it another try right now, I even reached the 7th wave, but no problems anymore. I tried several times. Strange. I mean, fine.

I just got my second Raspberry Pi 4 ... finally. It's the 8 GiB version which I'll use in particular to build MAME on (the 4 GiB runs out of memory and gets into heavy thrashing). So I can do some reshuffle at home; the previous Raspi 4 will replace the current Raspi 3, and that one could take the role of the TIPI Raspi. I suppose a Raspi 3 is enough for TIPI, right?

For me, TI Invaders had a well predictable hurdle where I used to stumble and eventually fall: This was in those rounds with the pink balls or the blue blinkers. Fun fact: Still today, I experience a weird, faint feeling of hope when I reach 6000 points to get another base (which I don't, of course). This was my hope back in 1982 when I saw that I got a base at 3000.

Why does this always sound like different working groups in the same company that don't really talk with each other or even understand what the others are doing ...

I can't even conceive how to dream in a programming language, as such a technical, formal language does not allow me to formulate my beliefs, desires, or intentions (→BDI model). However, as for riding a bicycle, one thing I have to object to: It may be like bicycle riding, i.e. at some time you learned how to formalize problems in that language (depends on the type of programming language, of course), and that is an aptitude that you probably won't forget again. But if you're working on concrete long-term projects, when you pause your activities for some time, say for four weeks only, you have a hard time recollecting everything to resume your work again. This is more like piano playing (or keyboard playing, as I do): You are constantly improving when you stick to it, but let it slide for some weeks, and you feel like a novice again.

If you want to use the new DSR in the MAME emulation, replace the file ti99_tipi.zip in your rompath with the attached file. However ... due to the nature of MAME, we will get checksum errors each time the ROMs are changed, unless I also change the checksums inside MAME for the TIPI ROM. Yes, this is intended and a Good ThingTM. These error messages can be ignored, but I think we cannot turn them off completely (this is, IIRC, also on purpose from the core devs). Does it make sense to update the checksums now, or do we expect more frequent changes in the DSR in the future? If so, I'd update the checksums in longer terms (every 3rd time or so). When I update them, users of the old DSR will get checksum errors, of course. ti99_tipi.zip

Back in the 80s, we played Parsec in turns, with 3 people. Whenever one of us lost a ship, it was the next one's turn. This lasted for some hours. No one could remember when it was the last time that the ship supply showed only 3 ships left. Finally, we chose one of us to crash the ships intentionally so that we limited them to at most 4. This went on ... and on ... and on ... I don't remember how this ended. The problem we saw was that with some basic practice, in higher rounds you could make 10000 points faster than losing a ship, so after round 15 or so, it was not really a challenge anymore. We made the points counter cycle at least once. Interestingly, I was still quite good at Parsec when we had it in our monthly games competition, but mostly when I ran it in the European 50Hz version. I'm much worse with the 60Hz version.

Is there a built DSR code file which I can pack into the ti99_tipi.zip for MAME? I just saw the source code on Github.

... and, of course, the Geneve emulation in MAME and its debugger. 🙂

I'd say as the bit level protocol for cassette is implemented in software, it should well be possible to define new carrier frequencies. Also, one could drop the backup records (each record is saved twice, as can be easily heard). Could be an interesting challenge.

Did work, but the Gotek is set to DS1, and the 5.25" drive to DS2 (if I remember my last successful attempt correctly), while it should have been DS0 (for DSK1) and DS1 (for DSK2). Something like that, I'd have to pull them out to check, but let's keep them where they are now. 🙂

BTW, here's how my Geneve system evolved lately - replacing the 3.5" floppy drive with the Gotek. And it's working! I had some struggles with the drive number jumpers, though. When I tried to pull the plug out of the 3.5" drive, it was so tight that I ripped the flat cable out of the plug. Luckily, I found another one, but with twisted drive selector lines from a PC. This is kind of a quiz game - which drive will light up now? (P.S.: If you wonder what is that SYSTEM/SYS with 1024 bytes size, it's my own SCSI loader.)

There is some interesting information about the 1541 on the German Wikipedia; translated by Google Translate: (Note that the VIC20 was sold in Germany as VC-20 because "F*ck" (insert i) in German corresponds to "F*ck" (insert u) in English, and "V" is pronounced "F" in German.) The price advantage of the serial bus was paid for with a greatly reduced transmission speed compared to the IEEE 488 bus. Since the control chip used, MOS Technology VIA (MOS 6522), turned out to be faulty in the implementation of its shift register for automatically sending and receiving a byte shortly before the VC 20 went on sale, this task had to be improvised and programmed suboptimally in a very short time. Access routines are taken over by the processor using bit banging. As a result, the transmission speed dropped again by about 1/4. Due to the small memory of the VC 20 and the correspondingly small size of its programs, the low loading speed was not so important. For printers of the time, the speed was more than sufficient anyway. Although the C64, in contrast to the VC 20, used the error-free CIA chips (MOS 6526) with regard to the implemented shift register, for reasons of space, none of the two pins of the CIA chips required for the hardware-accelerated variant of the serial bus were used on the printed circuit board of the C64 routed to serial port. In addition, for reasons of backward compatibility with the VC 20 and its VC1540 floppy disk drive, of which there were still significant stocks, the C64 continued to use the original version of the bus, in which the transmission of each bit from the CPUs in the C64 and the connected floppy disk drive was carried out individually had to be done. Also, the VC1541 floppy disk drive specially developed for the C64 was not built with the CIAs, but with the cheaper but faulty VIAs. Since the processor of the C64, unlike the VC 20, was stopped by the VIC II video chip once per line of text for at least 40 clock cycles, the bus speed had to be lowered again compared to the VC 20 so that the C64 did not have to wait during this waiting state Missed bit from floppy drive. In connection with the much larger memory of this computer, the loading times for extensive programs often increased to several minutes.

Just to avoid misunderstandings, my point did not target on aesthetic values of the command set, even if I used the word "nice". 🙂

The TI has the nicer machine language. 🙂

To be precise, as far as I know, the TMS9985 was also designed as a 16-bit processor, but with 8 data bus lines (like the TMS9995 in the Geneve). The bit count should only be used for the architectural width, not for the data bus width.

This is the usual IEEE 754 disease. People are often surprised to hear that all the single-decimal numbers 0.1, ... 0.9 are approximations with the exception of 0.5 which is precisely representable ... and that our TI, in contrast, can encode all of them exactly. While the radix 100 format is utterly slow, it allows us to encode all interesting numbers without approximation - interesting in the sense that I'd like to use them as a numerical constant in the program. I'm not interested in 0.02734375, although this can be done with IEEE, but rather in 0.1 or 3.21 or the like.

Oh, you mean inside ABASIC? I was talking about MDOS.

From Wiktionary: Borrowed from French console (“bracket”, noun), from consoler (“to console, to comfort”, verb). Sense of “bracket” either due to a bracket alleviating the load, or due to brackets being decorated with the Christian figure of a consolateur (“consoler”),[1] itself perhaps a pun on the first sense (alleviating load). Originally used for the bracket itself, then for wall-mounted tables (mounted with a bracket), then for free-standing tables placed against a wall. Use for control system dates at least to 1880s for an “organ console”; use for electrical or electronic control systems dates at least to 1930s in radio, television, and system control, particularly as “mixer console” or “control console”, attached to an equipment rack. This was popularized in computers by mainframes such as the IBM 704 (1954) in terms such as “operator’s console” or “console typewriter”, and then generalized to any attached equipment, particularly for user interaction. The automotive sense harks back to earlier use as “support”.

Parameter passing is no problem; I'm using that for my XModem tool. DEF CLILIN * Get arguments from CLI * Caller: * LI R1,BUFFER * BLWP @CLILIN * JEQ GOTIT * Buffer will be null-terminated H2000 DATA >2000 WS BSS 32 CLILIN DATA WS,START START MOV @>0128,R0 JNE ST1 SZC @H2000,R15 RTWP ST1 CLR R2 MOV @2(R13),R3 MOV *R0+,R1 LI R5,6 MOVB *R0+,R2 DEC R5 SRL R2,8 GL1 MOVB *R0+,*R3+ DEC R2 JEQ GOTALL GL2 DEC R5 JNE GL1 MOV R1,R0 JEQ GOTALL MOV *R0+,R1 LI R5,6 JMP GL1 GOTALL CLR R1 MOVB R1,*R3 SOC @H2000,R15 RTWP END

Summer not found either ... In the first half of July, temperatures rose until we had almost tropical nights (July 10), but in the second half we have some occasional sunny interruptions of rainy weather. Typically, August is the warmest month here, so let's see what we get. I call this skin-friendly summer weather (hello to all with skin type 1). (Conversions: 20°C = 68°F, 30°C = 86°F, 40°C = 104°F; temperatures sampled with my self-built ESP32 sensor node).

Hmm, seems as if TICLIB does not offer any function for speech, but neither does GeneveOS itself. Or have I overlooked something? I mean, in the end, you'd just have to map the speech synthesizer ports into the logical space, and then do the usual processing as described in the Editor/Assembler manual. It needs a string search like in Extended Basic, though, to browse through the vocabulary.

The emulator does the exactly same thing as defined by your program, or it would not be an emulator. 🙂 As for the memory contents, I tried to mimic that in MAME by preloading the 32K expansion with FF00 in all memory locations. I know of some software that depends on that pattern (TurboPasc'99) to detect whether the program is already in memory. You can check this by switching from the box expansion (32kmem) to the on-board mod (Console 32K memory upgrade (16 bit)) which is not preloaded. From my experience with the real hardware, memory is clear on startup; there is no random contents. The FF00 pattern is an artifact of the DRAM organization of the 32k board.

Ah, that's not so certain. I see crashes on MAME that look identical to the real machine. The only thing that is not really well emulated are physical tolerances and thermal behavior.