mizapf

You also see that none of the emulations are contributed by MESS (only MAME), so the reason may be that MESS has too high hardware requirements that the Raspi cannot deliver. Maybe another emulation like Classic99 (via wine) would have made it.

Are we talking about this manual: (first 8 pages) BTW, I tried tesseract for OCR, see the attached txt file. abasic.pdf abasic.txt

Will this qualify as "real iron"? Or somewhat closer to it than a mere emulation? I know some of you have more sympathy towards the real hardware, but eventually, in my view, this looks a bit like a body/soul discussion. - If the emulation behaves in a way virtually indistinguishable from the real hardware, does it make sense to make a distinction? - How much change or enhancement can be applied to the real hardware before it ceases to be TI computer?

As we already have a working HFDC in the emulation there is not a high priority for the SCSI emulation (accordingly, it is a bit further down my list). But remember that we're not emulating stuff in MESS only to make it easier to use but to preserve the technology.

Yes, the EVPC with a 9938 on board, and the HSGPL for the GROMs. Essentially, the SGCPU was just the final step to get rid of the console, just like the Geneve (hehe, I know Michael B. will be upset for me comparing the SGCPU with the Geneve ).

I cannot speak for the SNUG people - next one to ask would be Harald Glaab who also appeared here on the forum; I don't know whether Michael Becker also lurks here. From my last impressions I'd guess that there will be no further hardware manufacturing from them. I believe, though, that they'd be open for fair proposals, maybe a kind of licensing? Keep in mind that you need a TI console to decompose in order to build up a SGCPU card. SCSI emulation is on my list, but still way to go. As the lecture period is over now there's hope for some more time to spend on MESS.

For MESS users I just prepared a cartridge. Obviously this cartridge uses a GROM emulation (8K), and I don't know whether and where it is equipped with RAM. advertiser.rpk

The Geneve mouse is connected to the v9938 bus; I think it is Atari ST-compatible. For mapping the PC mouse to the emulated Geneve mouse you must add "-mouse" to the command line. (The same is true for the Mechatronics Mouse emulation.)

The text tries to sound lyrical; this is lost in translation. "In the realm of dragon Anaut your bride is kept prisoner. You will curse your way many times while you keep searching the castle of the dragon. When you reach it you will still find it locked." (next screen) "But a spell may help, once you found the four elvish harps. For the battle with the dragon you will need your sword and your bravery, there will be wounds and there will be blood. It will be a battle for life - see if you can win." (next screen) You play with joystick 1, fire button = use sword. At the beginning you have 100% energy and 5 lives. When your energy is gone you will lose a life. When your energy rises beyond 250% you will be awarded an extra life in turn for 125%. When you lose all lives, the game is over." (next screen) "Table of values / Energy Points / Use sword -1 (1 sec.) / Kill beast -5 +25 / Touch beast -? / Harp +250 / Coin +50 / Shield +75 / Fungus +50 +100"

<sigh> Rasmus still seems to not understand what has long been proven as impossible on the TI.

Long ago I learned to write some programs with Tex-Forth but then tried to completely forget the language again (in particular when c99 came up). There's no need to love all languages. (fbForth and other Forth interpreters are great tools, nevertheless; I don't want to put anyone off writing Forth programs.)

Although this is a nice effect, my visual mind seems to get confused and cannot make sense of it. Why are stars running faster near the ground? Are they closer to the observer than the ones at the top? In my opinion it would be better to have a very slow speed for the stars from the top to the bottom, and close objects passing by fast.

Interestingly, the problem is not the 8-bit bus but the fact that the processor has a 16-bit bus and byte operations. Almost all write operations to memory imply a previous read operation so that the processor can fill in the unchanged byte. Maybe due to simplicity in the microcoding, the word operations also use read-before-write. I did some research for my lectures to find out how they did it on x86. The 8086 also has a 16 bit data bus and word and byte operations, but Intel solved it much better: They added the LSB of the address bus (A0, but called A15 on the TI) and another line called Bus High Enable (BHE). With these two lines you can control what byte in memory shall be changed. The later processors (386 and later) use one control line per 8 bit of the data bus. Also, the 8088 (the actual IBM PC (XT) processor) only uses an 8 bit data bus like the TMS9995 (Geneve, TI-99/8), including byte multiplexing, which is also done on the TI-99/4A main board. So we have to admit that the TMS9900 architecture was a bad design at that point. Others did better.

*** FOOTBALL WORLD CHAMPION!!!! *** (sorry for all of you less interested, I'm usually not a real football fan either, but this was a great game!)

Hi Robert, try to unpack the zip file and re-pack with zip. Worked for me.

Well ... not really ... still two different leagues. The 68000 processor already had an address space of 32 bit, and even with the TMS99000 we'd be stuck with our 16 bits. Add as much memory as you want, we know it well from the Geneve - your processes only see 64K. There is of course a way, using bank switching, but this is not transparent, so you always have to split your buffers in some way to fit into the pages. The instruction set architecture just does not allow for more. On PCs, until only few years ago, the logical address space (4 GiB) was much larger than the physical memory. When this grew to today's size, 64 bit systems became useful. The Geneve and the TI-99/8 have much more physical memory than they can access, and so none of them, including 99000, can really provide something like reasonable memory management. The best thing to do with that memory is either multitasking with several processes (each getting 64 K) or exploiting the memory as separate pages, like memory files, or known from DOS ages, like EMS.

I actually have the printed manual - but not scanned (yet). Although I do have a flatbed scanner, I'll first check whether I can get it scanned with a document feeder.

I believe that with the availability of the Geneve via MESS, many more people could be tempted to give it a try. There's still so much potential in this machine. Still, as I said, we need some guidance for beginners, and I'll start to set up compilations of useful programs to be downloaded from WHTech. We can still take down those programs when the authors do not agree. Tim, maybe you could also check your software collection for some useful tools. I'll upload them to WHTech. Fin..a...al - oh...hoooooh ... (Sorry, must have been a flashback from yesterday's football world-cup semi-final)

There is, somewhere, but as with most command shells, you'll make use of 20% of the commands for 80% of the time. That is, you'll get pretty far with DIR, CD, COPY, REN, DEL, MD, RD, FORMAT, TYPE. @Tim/other Geneve users: In regular intervals the idea recurs to my mind that we should set up a collection of DSK images with useful Geneve applications. We can upload that collection to WHTech and put some links on the Geneve home page. Maybe with some sections like "Editors", "Assemblers", "Graphics", "High-Level languages", "Word processors", "System tools" etc. The only problem is that there are some programs that were distributed commercially (like Fortran 9640), so maybe this can raise some issues when we offer it for download. I found some really interesting tools in the 9640 News collection, but which may only be found by chance.

You know, the Geneve is really good at being DOS-like and supporting hard disks. (I mean, you're using an emulation already.)

Just tried, yes, ROM-only cartridges do not work with the multi-cart slot (check e.g. Defender). Maybe I explicitly disabled it (have to check, don't remember every detail :-) ). The multi-cart slot does not work without GROMs. However, you can choose the respective slot using the OSD menu (Dip switches, "Multi-cartridge slot"); I just checked it.

Some cartridges can only run on the base GROM bank (like Parsec), since they have hardcoded 9800 address references. Also, ROM-only cartridges will not show up in the list when not mounted in the cart1 slot because the slot can only be activated by a GROM access to the respective base address. You can still select the slot in the "Navarone style" by going into the OSD menu and then manually select the cartridge. Do the cartridges show up in the cart1 slot? [Edit: I did not see your recent message. So the cartridges do not show up in cart1? This should work, actually. What about the standard TI-99/4A?]

I just tried it in MESS. You can exit the load routine by pressing E, letting it continue with PRESS CASSETTE STOP - THEN PRESS ENTER. After that you get an I/O error. Interestingly, the consequences differ, whether you use TI BASIC or Extended Basic and whether you have a 32 K memory expansion. Only when you do it in Extended Basic without memory expansion, the memory is cleared, and the program is gone.

Long ago, after one long afternoon of typing in an Extended BASIC program (with no memory expansion), just a few lines before the end ... ... I accidentally typed OLD CS1

In my opinion it does not make sense to have a map with people who are not members of our TI community. We don't want to impress others with our number, we just want to see where on Earth we are.