mizapf
-
Content Count
5,351 -
Joined
-
Last visited
-
Days Won
3
Posts posted by mizapf
-
-
With discussions like these I sometimes ask myself whether we would have done better in some way, judging in hindsight.
Suppose we had the same hardware pieces (CPU, VDP, sound, 9901).
One thing that we already agreed on is that the separation of video and CPU RAM contributes much to the bad performance, where other 8-bit systems mapped their video RAM into the CPU address space. Would this have been an option for our system? I think the issue begins already with the approach to use this video co-processor. It sounds reasonable at first, though.
First, the VDP RAM is organized differently to the RAM in the CPU space. AFAIK the VDP includes a memory controller, implementing refresh cycles on its own, while the RAM in the CPU space must be SRAM or - as found in the 32 KiB expansion card - DRAM with an own memory refresh circuitry.
Second, the VDP is a kind of processor on its own, so the memory would become a shared resource. This would imply some coordination for memory access from the VDP and from the CPU. Also, the VDP must access the RAM for composing the video image all the time.
Third, where would we have mapped the video RAM? There must be an area for the operating system (Monitor), which essentially realizes a virtual (GPL) machine in our case (how ironic that GPL looks much like an 8-bit system). Where should we reserve a 16 KiB area for the VDP? Maybe at the top of memory (C000-FFFF), which leaves only 8 KiB (A000-BFFF) for programs. Not a good idea. Maybe a full 16 KiB window is just too large.
An alternative would be to use a window of 4 KiB, e.g. in 3000-3fff, with 4 banks, using CRU to switch between them. This would have meant to reorganize memory as 16 * 4 KiB so that this area could have been reserved.
Your ideas?
Michael
-
Here are my statistics for opcode frequency, taken from some code samples. I cannot say how representative the samples are, though, but I needed this for ordering the command lookup in the CPU emulation in MESS. (Later, however, I switched to some kind of B-tree which proved to be much faster). One obvious peculiarity is the XOP which is surprisingly often ... and some of us may probably guess that the code is from Geneve programs.
1. MOV
2. LI
3. BL
4. C
5. JEQ
6. JNE
7. JMP
8. B
9. CLR
10. A
11. BLWP
12. AI
13. CI
14. DEC
15. INC
16. SWPB
17. SRL
18. ANDI
19. SLA
20. XOP
21. INCT
22. JL
23. MPY
24. SOC
25. STCR
26. SETO
27. JLT
28. DECT
29. JHE
30. JH
31. DIV
32. ORI
33. JOC
34. JGT
35. LIMI
36. ABS
37. CZC
38. RTWP
39. JLE
40. SRA
41. SBO
42. JNC
43. INV
44. NEG
45. X
46. SBZ
47. LWPI
48. SRC
49. TB
50. LST (Geneve)
51. JOP
52. STWP
53. STST
54. JNO
55. DIVS (Geneve)
Not occured: RSET, LREX, IDLE, MPYS (Geneve), CKON, CKOF, LWP (Geneve), XOR
Also, COC, LDCR, SZC, and S are not included since their values occur in ASCII text.
-
1
-
-
IIRC there are some cases where PC disk controllers have real trouble when reading the TI disks, related to the first sector on the track. In that case the file transfer via XModem may be the only way out. On the other hand, as I said, I was able to read more than 90% of my old TI floppies right away, so this method worked sufficiently well for me. Nevertheless, today, for single files I'm using XModem because it is quicker. Copying back to disk means you always have to write the whole image back, always with some probability of failure.
My suggestion: Use the floppy drive for mass transfer between TI and PC. Later, use XModem for synchronizing.
If you plan to install MESS please have a look at my notes at http://www.ninerpedia.org/index.php/MESS . This should clear up most of the initial issues. For most Linux distributions you have to make sure that you have installed the necessary libraries (like GTK2, SDL, SDL_ttf, Qt4).
-
I got a 5,25" drive from ebay for about €20,-. Yes, it's difficult to get some. You can also think about attaching a 3,5" drive to the TI, but keep in mind that there may be problems with 40/80 tracks and in particular HD disks.
-
Do you have a floppy drive in your PC that fits the drive of your TI? I could offer you a simple copy tool in Linux which can read and write TI disks. This way I backed up my whole disk collection as disk images (well, almost, except for some really unreadable disks).
-
I've used putty in Windows only to get the ssh and scp tools that are included in Linux, so why use putty? Can it handle XModem?
I included an XModem implementation in TIImageTool (see the resources collection in this forum). You need Java 5 or higher and the RXTX library to access the serial interface. After installing you should be able to exchange files with the TI or Geneve on the other side using TELCO or other Terminal Emulators (except for the TE-II, as Owen already said).
Michael
-
The 99/4A seemed to be attractive to those who were less interested in gaming. Even the Geneve seems to mostly use the 9938 VDP and extra VRAM for multiple pages of 80-column text (yawn).And for pictures like this one (from my Fractals program on the Geneve). Well, I admit, the Mandelbrot set is a bit "eighties", from today's point of view (and I got the Geneve in 1990).
Yes, much more would have been possible.
-
1
-
-
MESS can load cassette images, but not directly load from the mic jack. You can use a recording tool on the PC to first save the cassette data to a WAV file. This can be mounted in MESS as a cassette image. Results can be improved by using some audio tools first (like audacity) to remove noise in the signal and to create more regular wave forms. This indeed worked for some of my old cassettes.
-
Tim, please don't spoil my dreams ... :-) I always hoped for a bright 9938 future with games with sophisticated graphics, at least at C64 level. (SCNR)
Some ideas:
1. Full screen scrolling should rarely be needed, maybe limited to some rectangular area.
2. Maybe I should really try to benchmark the commands to have some numbers. I already mentioned my benchmark tool which takes the time from the RTC on the Geneve.
3. I already suspected that some commands may be too slow to be suitable for all cases. In my Fractals program I used the fill command to wipe the screen, and I had to split it in two actions (because you cannot fill the whole screen in one go). I remember that I could see when the first and second wipe happened, and everything you can see is too slow, i.e. it happens in times of more than 100 ms.
-
The pure MHz numbers are not a good indication about the performance of an emulation. For MESS I can say, since I've been working on its TI/Geneve part for some years now, the issue is that basically everything happens in a single thread. There are some ways to employ multithreading, but this mainly helps out on the display side (the docs of the configuation options say "this enables rendering and blitting on a separate thread").
So for a single cycle that you see in the 3 MHz TI, we have to do everything in serial that actually happens at this time in parallel, including the CPU activity, the selection of circuits out there on the board, the video processing, the sound processing, the speech processing, generation of wait states, decrementing timers etc.
Thus, different to hardware (as already mentioned here), when a line is set, I have to loop through all devices on that line to set the value. Every single time. This proved to be painful in the TI-99/8 when going through its large GROM library every time I access the GROM area. Hence, I rearranged the list so that the main GROMs are found first, but this is actually not a really good solution (because it defers the problem to the rarely used parts and does not solve it).
The situation got a bit more difficult when I rewrote the CPU cores to more closely emulate the microprogramming (we discussed that already ... I know this may be pretty different to the real hardware, but it is done in a way that I have to go for a pure non-parallel software solution) pushing up the CPU load. I can at least say that the emulation up to the 99/8 and the Geneve runs at full speed on a single core with about 2.6 GHz.
(Recently there were some issues with the C64 part in MESS, after they rewrote the 18 MHz floppy controller, which slowed the whole emulation down to 30% - note, on a QuadCore system! I have to check whether they actually solved that issue; did not check it recently.
valgrind is our friend for discovering hot spots in the code, and that is, we really need to use it.
-
The 9938 has a move command where you specify a rectangle on the screen and where to move it. This is quite fast, as it happens all inside the 9938.
See the V9938 manual, section 4.3 (high speed move VRAM to VRAM).
-
FWIW, I just purchased a Raspberry PI Model 2 last week, and it's definitely an impressive piece of hardware. As soon as I find out how to compile MAME/MESS for this platform I'll surely try how far we can get ... although I tend to believe it won't deliver enough processing power.
-
I guess there won't be much time left to do anything else but screen updates
.Actually, I did not even think about the multicolor mode ... could it be we finally find some reasonable use for this strange mode?
-
One particular problem that we have with our TI architecture is that the video RAM is only accessible with load / store operations on a byte basis. We are desperately lacking logical operations, moves, calculations. The C64 mapped the video RAM into the main memory so the CPU had direct access. Of course, they were also playing a lot with the scan line interrupt.
I believe that we could have achieved much more with the 9938. It has built-in screen operations, and this is what I already used in my Fractals program, for instance, when pulling open a zoom window. Also, I once wrote a program with background music and a candle with a flickering flame. I implemented this as a set of eight images of the flame which I put into the non-displayed area and did a move of the rectangle around the flame to the top of the candle. Also, with the 9938 commands we have move operations so we could pretty easily create soft-scrolling displays. I think I'll do some benchmarks to find out more about the processing speed so we can estimate the change rate depending on the size of the area.
None of that is possible with the TI-99/4A VDP. What you can do (I think this has been mentioned) is to pre-draw screens and to exchange different screens using the video registers. For instance, in the Graphics 1 mode we could point to different pattern descriptor tables. However, the register only allows for setting the PDT at >0800 multiples, so this gives us at most 8 such tables. Another chance would be to swap the screen image table and to fill the PDT with shifted patterns. But this is again only possible at >0400 multiples, hence 16 variants. In bitmap mode one could maybe create some nice effects with a clever definition of the screen image.
As soon as you need to replace the screens from the CPU memory you have to to a costly transfer from the CPU RAM. Before saying that this is a showstopper, however, one should calculate or measure the actual data rate that we can achieve at most, so maybe this suffices for some applications.
Sorry for being pessimistic, but - to sound a bit more positive - this will be a real challenge. I just don't believe the game authors of other computer platforms were much more adept than ours, but we know it ended up in a bunch of ... well ... not-so-attractive games. With some notable exceptions, certainly.
-
Yes, Thierry ... I should really keep a bookmark of his pages, and right at the start of the list. He seems to have invested quite some research already, so this seems to be the answer to many of these questions.
-
Thanks Stuart, I just had a look, but they do not show all tags either. There are some exotic ones which I was able to tickle out of the assembler, so the list, as far as I found them in the test, would be
0x01 / byte[8] = Identifier, compressed object code
0 / byte[8] = Identifier (all following int16, byte represented as hex strings)
1 / int16 = Program entry ("END XXX"), absolute address
2 / int16 = Program entry, relocatable address
3 / int16 byte[6] = REF (relocatable address, symbol)
4 / int16 byte[6] = REF (absolute address, symbol)
5 / int16 byte[6] = DEF (relocatable address, symbol)
6 / int16 byte[6] = DEF (absolute address, symbol)
7 / int16 = Checksum (value)
8 / int16 = Checksum (value, ignored)
9 / int16 = Absolute location (location counter, from AORG)
A / int16 = Program-relocatable location (location counter, RORG, default)
B / int16 = Absolute contents
C / int16 = Program-relocatable contents (usually a reloc. address pointer)
D / int16 = Load bias (address where to start loading, not supported)
F / null = end of record
I / byte[8]? = Segment identifier (ignored; according to E/A manual; how to create?)
M / int16 byte[6] int16 = Segment declaration (length in bytes, $DATA for DSEG and $BLANK for CSEG, id?)
N / int16 int16 = Common-relocatable data (location counter, id?)
P / int16 int 16 = Common segment definition (location counter, id?; created by CSEG)
S / int16 = Data segment definition (location counter, created by DSEG)
T / int16 = Data-relocatable data (location counter)
U / int16 byte[6] = Load symbol (?, created by LOAD)
V / int16 byte[6] = Secondary reference (?, created by SREF)
: / null = End of file
The segments seem to show that they planned to be able to build some Harvard architecture computers with the TMS9900. With the standard Von Neumann style (and no special memory handling) there was no need to include them in the loader.
-
So to clarify why I posted this (apart from the possibility that some of you always wanted to know what PSEG / DSEG / CSEG is but never dared to ask or try), my question:
Does anybody have a full description of the TMS9900 tagged object code? The information from the Editor/Assembler manual unfortunately leaves out most information that is not applicable for the built-in loader.
-
Doing some "forbidden things" here
...I was curious to see what effect this has on the produced tagged object code. So this gives us some more tags, which TI should have told us about if they really meant it seriously with that "appropriate loader". Concretely, I'm about to add a disassembler for D/F 80 files to TIImageTool, so for the sake of completeness I'd like to find out about the additional tags we never heard of.
The appropriate loader was something we never got to see, right? We did a lot of things in the past 30 years, but nothing here. Or did I miss something?
As far as I can see, as with many other platforms, the assembler allows for defining a data area in the program as well as a text area (called program area here). Third, we can have a common segment. Obviously there should be three independent location counters in the loader; the standard loader only knows a single one, beside the absolute address counter.
Watch how the assembler marks the different relocation classes.
(I'm adding this as a text file since I could not get bbcode to keep the spaces and not play with tabs.)
-
1
-
-
Looks a bit like Space Taxi (C64). I always hoped for someone to port it.
-
You should have a look at the document ftp://ftp.whtech.com/datasheets%20and%20manuals/Datasheets%20-%20TI/9900-FamilySystemsDesign-1stEdition/9900-FamilySystemsDesign-04-Hardware%20Design.pdf. This was arguably the most important document for my works on the 99xx CPUs in MESS. On pages 4-45 ff. you have a detailed description of the CRU and external instructions.
I am not 100% sure, but my guess would be that nothing noticeable happens except that the 9901 may be put into interrupt mode if it was in clock mode before. This is the case because the console does not decode A0-A2, which are nonzero for the external instructions, and I *assume* that A3-A15 are zero (but I have not found real evidence for this) which would select the 9901.
In the same document on page 4-102 we can find the steps of command execution, and after setting the address bus with the location of the command there is a sequence of "NC" (no change) until there is a line "AB=external instruction code" (AB=address bus). Bu they do not say whether bits A3-A15 are affected, only which values show up on A0-A2. If A3-A15 are zeroed, we have an access to address 0 of the console 9901 (which is the mode bit); if not, there would be the part of the address of the control instruction (where it was loaded from), and this could have an effect on any device connected to the CRU bus (depending on the location of the instruction).
There is also some note that there is no output on the CRUOUT during an external instruction. This would also raise the question if the line is floating during that time or if it is low. In any case, this would only mean something for the 9901 if the above thoughts are right.
-
By the way, the TM990/189 systems had a bunch of features invoked by the "discouraged commands", i.e. there was circuitry for LREX (reboot via LOAD interrupt), RSET (not used), CKOF/CKON (tape motor control), IDLE (idle state, signalled by a LED). I had to learn a bit of these systems when I rewrote the 9902 (RS232) and 9901 in MESS and after that earned the job to get that 990/189 running again.
With the IDLE you could do a "wait for vsync".
-
By the way, Robotron reminds me of another game which I very much enjoyed, and I just tried it once more: Guardian. Also with robots, they try to carry away the energy pods on the screen, and with later levels you're getting more and more stressed, as several of them carry them away in different directions.
Guardian has some peculiarity: it makes use of the IDLE opcode, which you can notice by the dimmed flex cable interface LED. (Too bad I still have not included things like external LEDs in MESS
) -
Matthew, thanks a lot for the elaborate answer! I'll have to save that message for some spare time to come during the next days ... hopefully ...
-
Hi Tursi,
I just tried to run Robotron 2084 in MESS, and the Enter key is working properly, so this may be fixed in the meantime. Seems as if I fixed that when rewriting the 9901 some time ago. The only thing I notice is that sometimes I get a black screen after the intro with the colored frames, and for two player game this always happens, so I have not yet seen a successful level start with two players. Also, QUIT seems to be broken; I get a blue backdrop, and a lockup.
[Edit: Correction, I just got a two player game working (players take turns when one has been killed). Sometimes, though, I'm getting a black screen only, and also for the single player game.]
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Pie in the sky?
in TI-99/4A Computers
Posted
This is a static code count, not the occurances during execution. I think I could easily include a printf in MESS inside the CPU emulation to find out about the occurances during runtime. This will, of course, heavily amplify the numbers of those commands that are used in loops.