mizapf

If my memory serves me right, there was a good reason why some of my projects were left unfinished, and it was not only my job. During that time in the mid-90s, I basically knew nobody with a Geneve, apart from two or three people here in Germany. You sometimes met those people at our TI-Treffen, but if the only person who was interested in finishing the game was yourself, well, then there were a lot of ways to downprioritize your project. It took some more years before we started to meet on newsgroups and the first list servers. The situation that we have today is one that I would have never expected twenty years ago. It could easily fuel the Infinite Improbability Drive (at least viewed from that time ago).

I wonder why they built the databus multiplexer in the console this way, low-before-high. Not only the 9995 does high-before-low, also the 9980A. So it seems it is the TI-99/4A console that deviates from the order.

I'm really, really cautious with soldering work on my Geneve system, but the 32K expansion was something I found easy enough, and I did it without any problems.

There are references to the Geneve TIC library, in particular functions that use the XOPs. If you look inside the code, you should see that I used lots of 9938 features.

I translated the comments in the source file, just if someone is interested how TIC programming on the Geneve looks like. arkanoid.c

Still on Ninerpedia: https://www.ninerpedia.org/wiki/Geneve_CPU_Memory_Upgrade

Here, SCSI2SD 5.0a. In Linux, I am using dd to dump the complete SD card to an image file, and vice versa. This is perfectly working for me, but I am using only a single partition.

But you did notice that there is no game in terms of scoring, next level etc. ? This was just my first attempt to see whether it would be working. It somewhat deserves to be finished at some time, I have to admit. The file time stamps (1995-1996) show that this was the time when I picked up my first full job as scientific assistant at the university. So it seems that the reason why I stopped working at it was that the hobby had to stand back for my profession. Some time later, however, I started my project of implementing a simple TCP/IP stack for the Geneve. This took longer than I was able to use an analog modem at our telephone network; we switched to ISDN. Thus, this project was not finished either; at least I was able to ping my Geneve from my PC (I got echo responses). Edit: For some more fun, you can edit the screen in ARKF. (from the source code, translated by me) /* Read the screen from arkf * = initial ball position # = wall 1x 2x 3x 4x hits before block is deleted ------------ A B C D ! red E F G H ! green I J K L ! magenta M N O P ! yellow Q R S T ! blue U V W X ! gray = = undestroyable */ The ARKF file looks like this: ################ # # # AAAAAAAAAA # # EEEEEEEEEE # # IIIIIIIIII # # MMMMMMMMMM # # QQQQQQQQQQ # # # # # # * # # # # # # # # # # # # # # # # # # # # # # # # # So you may have some more fun with own designs.

Sorry, my fault. There is a file missing on the disk image (ARKF). The file defines the playfield. (As I said, I barely remember my own game. I intended to load the screens from disk.) arkan.dsk

I don't know about version dependence, could be. I'm using 6.50, and I think it was TIC 1.61. I guess you don't have the 32K SRAM expansion, that's why you are using these very old releases. Edit: How it should look like.

No, this is native mode ("MDOS mode"). The memory layout of the native mode is very different from the GPL mode; for example, memory-mapped devices appear at addresses F100-F13F, not within the 8400-8Cxx area. You have contiguous logical memory from 0000 to EFFF. When you write programs with TIC (the C compiler), they are created for native mode, since they rely on the XOP library. In the above case, after booting GeneveOS, you switch to drive A: and run the program by its name. If it were written for GPL mode, you'd have to start the GPL interpreter and switch to TI mode. Or you use EXEC to run those programs. Edit: One thing to notice for native mode programs is that the files may become much longer. You often see program files up to 64 sectors, although they could become even longer, if I understand the XOP docs correctly.

Funny. I had a look on my Geneve hard drive, concerning the TIC programs that I wrote 25 years ago. Have you ever found yourself wondering whether you really wrote some program, and why you completely forgot about it? As it seems, I wrote a first concept of an Arkanoid for Geneve in TIC around 1995. I found some sheets of paper in a binder, but I did not remember I already came that far. Ar least you can already play it. (Mouse is needed, of course.) There is no doubt, it has the style of comments (in German) that I recognize as mine, and the odd brace placements of that time. Must be my program. arkan.dsk

The easiest way would be to have a TV with SCART input (e.g. I have a Samsung LE19B450). For a VGA monitor you need a 15 kHz scanline doubler, as far as I know.

One particular, important aspect that should be stressed is that the Geneve forms a platform of itself with a set of features that you can rely on as a programmer. Regardless of the value of all the classic and modern expansions of the TI, all of them certainly fascinating projects, the Geneve offers those features in a bundle. You have an advanced video processor with the V9938, you have a mouse, you have DRAM and SRAM memory, a PC keyboard, high performance, and one operating system. It is this combination what makes the machine so interesting to me. And, one of the major points as well, it is largely compatible with the TI-99/4A software. There are only a few programs that can't be run, for instance, when they access hardware directly (like the keyboard). But overall, I did not miss anything; you can tune down the speed so that old programs still run at a comfortable pace, or let it run and see how fast the 9995 actually is. Nowadays, I'm using my Geneve mostly on the MAME emulation, since I do not perceive any relevant difference to the real machine - but I keep it on my desk for verifying emulation on it. I believe I learned to live with emulation just by the GPL mode of the Geneve, which simulates the TI. It would be weird if an emulation software author did not like emulation, actually. While I wrote GPL mode programs at the beginning, I switched to native mode soon, since I believed this is the "true" mode to run the Geneve, with a better memory layout and of course the XOP support routines. Overall, the Geneve kept me in the TI community. I am pretty sure I would not be on this forum without it.

As for Speecoder, it does help a bit, but I had to learn where my tool has its limits. For instance, it refuses to create MERGE files when the resulting string would be longer than 255 bytes, and you have to clip the file by yourself. It might be simple to include a feature which automatically splits the speech strings, but - well - I don't really plan to put hands on my mostly uncommented assembly code from the late 80s. However, it does its job for assembly source code files, because there is no string length limitation. But in this case where you already have a text version of the LPC data, it would be much easier to write some python script or similar to turn the data into BYTE assembly code lines, without a detour through my program.

As for the AMIGO and the other chips, we may have a chance to re-engineer some things via my emulation in MAME, which proved to be functional (it works, it can't be too far from the real thing ). But that is certainly not enough, the CPU would need to be emulated by a FPGA and so on ... And the 22 GROMs should be emulated by something more handy...

Wasn't there a wide grant of rights to user groups? I don't know whether this encompassed the hardware as well.

Looks like PAL output.

Actually, I used my Speecoder tool to place the splits and stop codes, so this was not really a matter of luck.

By the way, does BlueWizard produce TMS5220 or TMS5200 LPC code? Our speech synthesizer is a TMS5200/TMS0285; the output will sound a bit different.

Tried in MAME, I got I/O ERROR 00 in 140 and 150 (trying to open SCS6....)

I always wondered why the mouse is so rarely used (among all systems with 9938). The mouse has a simple interface and works reliably, with two buttons (via 9938). Edit: Just to explain, the 9958 has no option for connecting a mouse. In turn, it has some more features and a larger color palette. I noticed that the EVPC2 already allowed for using the 9958 instead of the 9938, also explaining that the mouse interface was rarely used. If I had written more programs for the Geneve, I would have tried to employ the mouse as often as possible, but so it's just one major program (Fractals), which actually needs the mouse. So is it really the better graphics, the problems to still find a suitable mouse, or the availability of the chip? Regardless of the 9938/9958 decision, this is certainly a fantastic work of Fabrice.

Sounds like the databus multplexer, integrated in the 9995 (and supposedly also in the 9985).

According to the documentation of the EVPC2 you don't need a modified GROM0. There seems to be special DIP switch settings: (translated by me) Dip switch 2: In the operating system in GROM 0 in the console, some video registers are set with wrong values on startup so that the power-up routine in the DSR of the EVPC2 must fix these errors by copying the video memory areas. When the EVPC2 is used with a SGCPU and HSGPL, these wrong register values in GROM 0 may be fixed, which removes the need to copy the memory areas. If the EVPC2 is used in such an environment, activating DIP switch 2 speeds up the power-up process. Off = normal power-up On = fast power-up Dip switch 6: TI put an error in the original GROMs which causes the character set in TI Basic to be loaded at a wrong place, which in turn leads to a display of weird characters instead of text. The DSR may be configured to reset the VDP registers every 20ms to sane values so that the display is correct. Off = Leave video registers as is On = Reset video registers repeatedly All features described above are only meaningful for use with a console. When using a SGCPU and HSGPL, all glitches in the operating system are fixed so that neither a modified interrupt service nor other tricks to reset video registers need to be applied.

Did you try the MAUS program on my disk? This should be the fastest way to debug. If the numbers do not change, the mouse is not sensed. As for bypassing the TI menu screen, the GPL version I initially had did the same, which actually annoyed me, so I patched that skip out of my copy. (I seemed to miss that Master Title Screen.) Always funny to see that different people enjoy and hate the same feature. 🙂 Which cartridge is not working? Do you try to load it in the GPL interpreter screen?