Pie in the sky?

[RobertLM78]

A couple of projects that seem interesting for the TI:

 

Elite

http://en.wikipedia....ki/Elite_(game)

 

The other is slightly blasphemous - but hey :-) - GEOS

http://en.wikipedia....erating_system)

 

I know there are challenges to both - but are they completely out of the question - or just really hard? (My suspicion that Elite was never ported to the TI for just those design challenges).

 

Thanks for reading .

[samishal]

GEOS would be awesome. I think you would better luck using the 16 bit version as it will probably be designed for processors like the TMS9900. The majority of the work would be getting it to run which would more then likely require a rewrite of a lot of code.

[RobertLM78]

GEOS would be awesome. I think you would better luck using the 16 bit version as it will probably be designed for processors like the TMS9900. The majority of the work would be getting it to run which would more then likely require a rewrite of a lot of code.

I would imagine so . You're right - probably the 16-bit would be more appropriate - but the fact that they were able to do that with 8-bit processing power is amazing .

[Willsy]

For GeOS, I wouldn't do a port, as the source code would be very tied down to the hardware it was running from. I would start from scratch and just copy the look/feel/spirit of the software.

 

I would say it's very doable indeed on the 4A, with, say the SAMS 256/1024K memory expansion (the C64 had 64K of RAM, whereas we only have 32K, so using the SAMS memory card would be a better option).

 

Memory fragmentation can be an issue with graphical operating systems (if they're object based), so a nice memory allocation/de-allocation system would be an essential early ingredient from the get-go. Then it's a case of trying to make the correct design decisions regarding the window management system itself. For example, how would display data be buffered to the actual physical screen (region clipping), and what happens when windows overlap? For example, if a window opens on top of another window, what happens? Is the screen data of the underlying window saved somewhere in memory, or (my preference) when the top window is removed, do we send a "message" to the window underneath to ask it to re-draw itself?

 

If we're talking about sending messages to 'things' then we're really talking about objects and methods, so it might be a good idea to implement a simple object oriented system (not too hard - again, memory allocation/de-allocation is essential (and is made all the more complex by the design of the SAMS card with its banked memory)), and we're talking about message queues. Perhaps each "application" is an object, with a (dynamic) collection of Window objects. An API would provide system calls (so abstract away DSRLNK et al) and also abstract away the display.

 

A big job, but doable.

[InfernalKeith]

I just saw the Youtube video of Doom on a Commodore Vic 20, and I'm now inclined to believe that anything is possible.

 

I own Elite for the C64 but have never taken the time to delve into it. Is it the complexity of the game itself that seems insurmountable on the 99/4A, or the 3D line graphics?

[Willsy]

I'd say it's the wireframe, not the actual game itself. Recall that Elite actually orginated on the BBC Model B computer in the UK, and that machine had only 32K of RAM (and that 32K included the video RAM).

 

However, the video on the BBC is mapped into the CPU memory map, so it's easy (and fast) to read/write screen memory, so the frame update rate can be quite fast - fast enough, anyway. Our video memory is port mapped, which is a pain in the ass.

 

The other advantage that the 8-bitters have over us, which is often overlooked, is that they have an (mostly) 8-bit instruction word size, whereas all our instructions are 16 bits; thus you can get more instructions in 32K on an 8-bit machine than you can on a 9900 - it's not 100% more, but you might find you can get something like 50 to 60% more instructions "in" on an 8 bit CPU than you can on our 9900, where every instruction is 16-bit.

[Willsy]

I don't have the knowledge with graphics (all that sin/cos/atn shit ties me up in knots) but it would be a nice project for someone to get a simple wire-frame demo up on the TI - just a rotating cube or something.

 

I think even that is non-trivial. You'd be looking at (in our universe) an optimized Bresenham algorithm running in scratch-pad, and the pixel plot/un-plot routine also running in scratch-pad, if you you can fit them, and of couse the CPU registers.

 

Sometimes would be the guy for this. He already has most of the code from other projects/demos.

 

At least you wouldn't have to update the color table - Elite was single colour (on the BBC, at least), so you could run it in half bitmap mode (or whatever it's called!)

 

 

There's some incredible wire-frame stuff in the demo above (ZX Spectrum, an 8-bit Z80 running at 3mhz IIRC). The screen RAM on the ZX Spectrum is directly addressable by the Z80. It starts at $4000 - ah, those were the days

 

The ZX spectrum is an interesting machine from the TI persepctive, since the screen resolution on the Spectrum is identical to the TI - 256x192 so, theoretically at least, the TI can display any image that the Spectrum can - differing colour palettes not withstanding.

[RobertLM78]

For GeOS, I wouldn't do a port, as the source code would be very tied down to the hardware it was running from. I would start from scratch and just copy the look/feel/spirit of the software.

 

I would say it's very doable indeed on the 4A, with, say the SAMS 256/1024K memory expansion (the C64 had 64K of RAM, whereas we only have 32K, so using the SAMS memory card would be a better option).

I guess doing something more in the spirit of GEOS is more what I was thinking . Hmmm - I should get my hands on one of those SAMS expansions (if that's at all possible - there's a few after market pieces of hardware I'd like to get).

 

Memory fragmentation can be an issue with graphical operating systems (if they're object based), so a nice memory allocation/de-allocation system would be an essential early ingredient from the get-go. Then it's a case of trying to make the correct design decisions regarding the window management system itself. For example, how would display data be buffered to the actual physical screen (region clipping), and what happens when windows overlap? For example, if a window opens on top of another window, what happens? Is the screen data of the underlying window saved somewhere in memory, or (my preference) when the top window is removed, do we send a "message" to the window underneath to ask it to re-draw itself?

I like the idea of the redraw - it should, theoretically, save memory for working with the active window .

 

A big job, but doable.

That's the optimism I like to hear! And, yeah, it would be a huge job - but I think it could be fun, in a twisted way .

 

I just saw the Youtube video of Doom on a Commodore Vic 20, and I'm now inclined to believe that anything is possible.

Impressive - you should share the link, I'd love to see that

 

The ZX spectrum is an interesting machine from the TI persepctive, since the screen resolution on the Spectrum is identical to the TI - 256x192 so, theoretically at least, the TI can display any image that the Spectrum can - differing colour palettes not withstanding.

<starting to drool, thinking of Elite on a TI>

[Willsy]

 

Here's Elite running on the ZX Spectrum. There's some wire-frame action at 3:20. Note that the play-field is not full screen, it's maybe just over 50% of the screen area.

[RobertLM78]

Here's Elite running on the ZX Spectrum. There's some wire-frame action at 3:20. Note that the play-field is not full screen, it's maybe just over 50% of the screen area.

Neat to see it in action - I actually didn't find out about the Elite until I found its modern clone, Oolite (Object-Oriented) in 2011. See:

http://www.oolite.org/

[Willsy]

Doom on the VIC-20

 

Doom on the ZX-Spectrum (same screen res as the TI): (skip to about 1 minute in)

 

Note that the ZX Spectrum version runs on a 128K spectrum, so we're allowed to use the SAMS card

 

The Spectrum version is brilliant IMHO. I'd go for something like that, either using pattern mode (32x24) or half bitmap mode. Note that half bitmap mode on the TI (256x192 pixels, but 32x24 colour) is *exactly* what the ZX Spectrum has. And note also that the ZX does not have a 'character' based video mode of any kind - there's only one video mode - bitmap - which is 256x192 pixels (6144 bytes) and 32x24 color (768 bytes). Just to be clear, on the Spectrum, an 8x8 pixel block can have any pattern, but only one foreground and one background colour for the whole 8x8 block. I believe the TI VDP can reproduce that mode exactly.

[sometimes99er]

Sometimes would be the guy for this. He already has most of the code from other projects/demos.

 

If only I had the time. At least RasmusM and senior_falcon seem to have been there too.

 

[RobertLM78]

That Spectrum version is brilliant! I could definitely see myself playing that . Great find Willsy.

[sometimes99er]

I know there are challenges to both - but are they completely out of the question - or just really hard?

 

Yeah, I’d say they’re both doable - and time consuming. Some extras, apart from the stock console, will of course be needed.

 

Elite. All functionality is certainly possible. Let’s leave SAMS and F18A out here. - Comparable overall speed including loading is perhaps another question. The 9900 is good for something, but the TI-99/4A has a series of pros and cons. As we know there’s a bit of shoehorn design there. The cons might make it hard to level with ZX Spectrum, MSX and even C64. The 6502/6510 is not a bad performer.

 

GeOS. Harder. I’d go with what Mark said. SAMS is probably a must, but, is it now 128K switchable ROM, that might be another approach.

 

Edited May 14, 2013 by sometimes99er

[RobertLM78]

What's the word on this SAMS card? Ninerpedia suggests that it may be in production, but I'm not sure how up-to-date that is. The article says "The card is in production again as a kit (summer 2007)", but that's 6 years ago now.

[Opry99er]

You can find em. A few guys over on the TI-99 Yahoo User Group have some, if I recall correctly. Put out a ping there and someone will have something for ya. The SAMS development was pretty awesome... shame more users don't have the cards... Doesn't make sense to develop software for HARDWARE that's only in 2% of the setups used by the TI-99 community.

[RXB]

Really without the SAMS card making a game like that would spend 80% of the time loading off disk.

If we used a 9938 with 128K or 9958 with 256K it would really be something on a TI.

[matthew180]

The SAMS development was pretty awesome... shame more users don't have the cards... Doesn't make sense to develop software for HARDWARE that's only in 2% of the setups used by the TI-99 community.

 

That's the chicken-or-the-egg problem there. No one writes software for rare / limited hardware, yet no one makes hardware because very little software would actually get written.

 

Even if a SAMS-like card was readily available, I don't think you would see much software spring up and take advantage of it.

 

[matthew180]

If we used a 9938 with 128K or 9958 with 256K it would really be something on a TI.

 

You can't put a 9938/58 in a stock 99/4A without modification to the motherboard. Let me rephrase, you can't take *advantage* of the 9938/58 with a stock 99/4A because the 9938/58 have extra inputs from the host system to access features like the palette registers, extra status, and bulk register loads.

 

As an add-on card, yes you can use a 9938/58 (it is called the Geneve), but in that case why bother with extra RAM hiding behind another VDP, just go for a direct access RAM board with banking, i.e. a SAMS...

Edited May 14, 2013 by matthew180

[RXB]

I put full SAMS support in RXB way back in 2001

So 2012 also has full AMS support and even now does a better job of showing SAMS sizes

CALL INIT :: CALL SIZE ! Shows normal size and the lower 8K amount being used.

CALL AMSINIT :: CALL SIZE ! Shows normal size and the amount of SAMS memory.

 

I just posted demos of using the AMS not that long ago in RXB.

 

It is not hard to use the SAMS in RXB.

[matthew180]

The other advantage that the 8-bitters have over us, which is often overlooked, is that they have an (mostly) 8-bit instruction word size, whereas all our instructions are 16 bits; thus you can get more instructions in 32K on an 8-bit machine than you can on a 9900 - it's not 100% more, but you might find you can get something like 50 to 60% more instructions "in" on an 8 bit CPU than you can on our 9900, where every instruction is 16-bit.

 

I've seen this argument before, but I'm not sure I agree. On an 8-bit machine, so move a 16-bit value from one memory location to another is going to take more than a single 1-byte instruction. Even the worst case on the 9900 would be six bytes (src and dst are symbolic) and best case two bytes (register to register). Can you show me the equivalent on an 8-bit CPU?

 

[Willsy]

Hi Matt,

 

In the example you cite, it would be a 5 byte instruction, whereas the 9900 would be a six byte instruction.

Something like MOV R0,@>A000 is 4 bytes on a 9900 and 3 on a Z80 (IIRC).

 

So it's nowhere near a 50% saving, but you get the idea. I think the real saving would be on the single byte op-codes (INC, DEC, ADD, LD etc on Z80) - half the size. Of course, that depends on just how frequent they are in the code. IIRC isn't the MOV instruction the most prevalent instruction in 9900-land? That would be a LD instruction on the Z80, which can be a single 8 bit instruction, *or* a 16-bit instruction, depending on source/destination etc.

 

So yeah, it's muddly puddle to stare into!

[sometimes99er]

So yeah, it's muddly puddle to stare into!

 

Yep.

[matthew180]

I think the real saving would be on the single byte op-codes (INC, DEC, ADD, LD etc on Z80) - half the size.

 

True, but don't you have to set-up what is being incremented and get it into the accumulator or something like that (showing my lack of 8-bit CPU knowledge here)?

 

Of course, that depends on just how frequent they are in the code. IIRC isn't the MOV instruction the most prevalent instruction in 9900-land? That would be a LD instruction on the Z80, which can be a single 8 bit instruction, *or* a 16-bit instruction, depending on source/destination etc.

 

I think it is definitely the most used instruction, probably on most CPUs. Based on its roots (the PDP-11), the 9900 has an orthogonal instruction set, which may have just been an experiment in the PDP-11 and others to see how it compared to the RISC-like instruction sets that use discrete load and store instructions.

 

So yeah, it's muddly puddle to stare into!

 

Yes it is. I have to believe someone has looked into this and done studies. My feeling is that is evens out over the course of a program, based on many factors and the different ways you would solve the same problem on different CPUs. However, I think the overall *perception* is that 8-bit CPUs have more compact code. I don't think that is true in general, but I have not seen any research one way or the other.

 

I think you get more savings with byte-code where you are running against a virtual machine. That way a single byte-code instruction can perform what would be many assembly instructions, thus you get better instruction density with the byte-code and trade off some speed and control.

 

[+mizapf]

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.