IEEE-488 card with TMS9914A controller

[IEEE-488 card with TMS9914A controller]

On 2/9/2019 at 1:34 PM, Ksarul said:

There is a version of the schematic here in the schematics thread too, so you can get a nice clear print of both versions of the TI board (yes, there were two variants). Those schematics also have the equations for the PAL, so you just need to resynthesize them to get the proper JEDEC file to program a chip. . .

 

There were also quite a few printers with an IEEE interface, and as the bus supported multiple masters, you could also use it to interface computers in a simple workgroup using the same peripheral equipment.

I've never worked with an instrument that was GPIB exclusively. 

 

So GPIB or IEEE-488 remaind just a curiosity. Curious, in that I have several computers with GPIB controller-card, but no peripherals to connect to them!

 

When I was a teenager, I would notice HP plotters in universities and elsewhere. I guess these were the HP-7470, 7475, or HP-7440A types.  My high school had a donated one, with working pens. 

 

My brother spent a lot of effort using one of those, using Extended Basic to plot conic sections, by sending HPGL. But, it had the RS232 port. Almost everything I come across from the 80s has RS232. (With that plotter, my brother made parabolic dishes.)

 

If I had a 99/4A IEEE-488 card, and a scope with GPIB option, I think it would be amusing to "close the loop". Use it to capture the PEB bus signals and display them in bitmap mode.  This would require a logic analyzer, or at least a sampling scope. I have a little experience programming their descendants, that standardized on VISA, SCPI, etc sequences.

 

"Closing the loop" would just be a neat trick, since the tools to do that job are already on my desk.
 

 

[CB Wilson - TI-99 related documents]

14 hours ago, acadiel said:

Now, this was in the same binder as the Morse Code stuff, and right before the subsequent GROM Testing stuff (which will be in probably tomorrow's post).  It's schematics relating to Video.

 

Anyone have any ideas what this is?  

 

Unknown_Video_Schematics.pdf 16.47 MB · 20 downloads

I think this is a genlock circuit. For superimposing of the VDP frame over external video frame.

 

The 1368 is a clue. Dividing the clock frequency 10.76MHz by 1368 gives the horizontal sync frequency. 

 

A PLL is a device that adjusts a clock up or down until two signals are synchronized. In this case it adjusts the clock to the internal VDP until the two frames are synchronized.

 

The other divide-by-455 stage is interesting. This has something to do with wireless remote control!

 

[Camel99 Forth Information goes here]

On 12/3/2020 at 7:57 AM, TheBF said:

 

: #@    ( addr -- n) DUP    @@ TOS MOV, ;
: @     ( TOSaddr -- n) *TOS TOS MOV, ;
: #[email protected]   ( addr -- c) DUP   @@ TOS MOV,  TOS 8 SRL, ;
: [email protected]    ( TOSaddr -- c) *TOS TOS MOVB,  TOS 8 SRL,  ;

 

 

Pretty sure you meant

: C#@    ( addr -- c )  DUP  @@ TOS MOVB,  TOS 8 SRL, ;

since MOV would always fetch an even address.  You could have a case test for even/odd constant addresses, depending on whether the CPU was better at MOV or MOVB (16-bit or 8-bit bus resp).

 

I still don't understand @@. I think this compiles a symbolic address.

 

But why the DUP?   What's the difference between

8800 # @@ TOS MOV,

and

8800 #  #@

 

oh I see, the first one clobbers the run-time stack

So is that DUP compile time or run-time?

 

On 12/1/2020 at 9:13 PM, TheBF said:

"symbolic" or as I prefer to call it "direct" addressing. 

I was confused by this later on. I confused direct with register. All the TI manuals say:

 

Ts or Td

00 WS Register

01 WS Register Indirect

10 Symbolic / Indexed when D>0

11 WS Register Indirect auto increment

 

I guess it is clear now.

 

I'm struggling to keep up. Looking up @@ in Wycove Forth was interesting but more confusing.

 

 

[As 2020 comes to a close what were your TI highlights?]

Thanks to @InsaneMultitasker I have a fully working Geneve 9640 + HFDC in 2020.

 

(My original 9640 still works, plus I got working floppy drives for it)

 

[Geneve 2020 Questions and Answers!]

On 11/23/2020 at 5:10 PM, dhe said:

 

GPL Questions:

 

 

One of the mill stones MyARC had hanging about their neck, was being able to run module software.

   Their first decision was no plug in for module, they had Peter Hoddie, write C-Save.

 

 Issue 1, C-Save didn't know how to save all modules. 

 

 Then you often times had module files, and you thought, is this the FIXED moon patrol from Mike, or just an original dump of Moon Patrol?  There never was a good database of patches or fixed modules put together. (Still isn't).

 

 

Well, as far as what Geneve2020 will do with GPL, I really only have vague ideas about it. Working on GPL seems so remote when I'm working on getting the ROMs to boot!

 

Some ideas:

 

Through a "compatibility card", support actual GROM chips or at least copies. An actual cartridge interface , like a card reader on a ribbon cable. (the backplane has 4 or 8 slots, 3 of which are used.) That hardware is just pie in the sky at this point though. Module dump files will be the norm.

 

Standalone GPL, no need why it has to run under MDOS. This is easier in some ways because MDOS does some hacky things with memory pages for GPL.

Also if GPL gets its own memory slice (up to 2MB) it can have SAMS memory.

 

GPL under MDOS is still a goal--that just comes with supporting MDOS memory scheme. But boot to a totally separate GPL is easier to make, in a lot of ways.

 

Quote

I never saw from Myarc, what the maximum Grom banks that could be used.

    I also never clearly understood, if the Geneve could support modules with RAM memory like

       SuperSpace, SuperSpace II or Minimum.

    Also, Myarc promised P-Code compatibility, I heard rumors of a pcode file but never saw it.

         Now, this could have been for two reasons (or more) - their Grom Operation couldn't emulate a

         P-Card, the Geneve's hardware wasn't compatible with a p-card. Maybe someone got it to run and all the disk-based utility had problems, not unlike some of the modules, or faster term, etc.

 

         In Candyland, I'd like to have full emulation of the P-Code card, and maybe emulation of the SNUG HSGPL card.

 

I really have not thought about any of that. 

 

Bank switched modules like XB use a special pair of page#s. I've not heard of Mini Memory implemented. My memory mapper is 4K pages at the core, as TI intended, so I think I can make Mini Memory 4K RAM 4K ROM by clearing the ReadOnly bit on half.

 

I think Myarc had somebody do a software USCD Pascal. Never officially released. No Pcode card involved.

 

Pcode is pretty far out.

 

 

 

Quote

 

Issue 2, Not all modules worked on the Geneve. I remember Mike Maksimik spent a lot of time making modules work.

              Broadly speaking problems seemed to fall in to four large categories.

              a) Bad hygiene on VDP register setup, things you got away with on the TMS9918, no longer did

                        you get away with 96k of RAM and much more complicated V9938 with more registers.

              b) Modules that either played fast and loose with the KSCAN routine, or tried to directly access the keyboard and joysticks via CRU.

              c) Direct access to I/O devices like the sound chip.

              d) Loose programming that worked on the 4A, because the 256 bytes of scratch pad RAM would roll over.

 

This will still be an issue, of patched versions needed.

 

a) VDP Register hygiene. I might be able to help with this, its a long shot. I believe the video card is going to cache all VDP register writes as they go on chip. This enables rapid context switching (putting MDOS in the "background" while a debugger takes over the screen, then switching it back). At least, you could look at what registers changed, and diagnose bad software hygiene. At a stretch, I could make some feature that intervened when a pure GPL program tries to write to regs #8 and up. Like, it GPL hygiene bit is enabled, cause a page fault when VR#8 or above is written. You then approve deny or ignore all such writes, kind of like when Windows asks you if you want a program to be able to write to a file. Or you just run it with writes to VR#8+ ignored (which would disable certain 80-column features like blinky text, or programs that use more than 16K of the VRAM.)

 

b) KSCAN. I have spent way too much time solving this! It was fun.

 

So many things are solved neatly by including a second 9901 chip for GPL to read from. 

 

This will be a 9901 at >0000, dedicated to the MDOS/GPL emulation. Programs that directly read bits from the CRU will see real hardware inputs there. For joysticks that's already what MDOS does.

 

As for how this enables them to see the PS/2 keyboard in KSCAN? When the OS gets a keypress, it has to at least put it into the MDOS register at >F110. So.. it can do lots of other processing. One job is a  lookup table for what CRU bits map to that key on the 4A keyboard, and to load those into a hardware register for GPL to read.  (The 4A has 3 row output selectors to address 8 8-bit read locations.) It is a complicated table--eg pressing ? on the PS2 keyboard is Shift Slash, but ? on the 4A is FCTN I.

 

So when ? is the actual character, it ORs the bits for FCTN + I to the 4A register.  This will, unavoidable, produce a lot of phantom keys (use ? for player 2 up direction I...) Worse, pressing UP-ARROW EQUAL will execute FCTN SHIFT QUIT. Its not perfect but it is great for playing games that scan for player keys. Just don't push UP-ARROW EQUAL.  SHIFT SINGLE-QUOTE produces FCTN P, and so on. Pretty much, be careful never to touch the = key and anything else when in GPL... maybe that needs to be a special case exception, huh.

 

And one more thing... because the 9901 has all the keyboard input/outputs and an external register, it is designed to have you connect a physical 4A keyboard that overrides the register. There is a connector right next to the joysticks for it. It shares the same circuit as the joysticks require. 

 

 

MDOS/GPL and Interrupts

 

4A has INT1 VDP,   INT2 P-Box interrupt  Both call the INT1 handler in GPL because the 9900 interrupt level input is hardwired at 1 (Why???)

 

GPL will see its interrupt level 1 or 2 flags. The "real" 9901 actually takes INT4 for peripherals, but sets bit 1 for GPL to see.

 

 

That is:

 

Real 9901 at CRU >2000 gets INT1 in at >2002

BIOS executes VDP interrupt handler

BIOS sets INT1 bit at CRU >0002

BIOS branches to GPL or MDOS VDP interrupt.

(not perfect yet but I believe it's workable)

 

Real 9901 at CRU >2000 gets INT4 (peripheral) in at >2008 or INT7 (keyboard) at >200E etc.

BIOS executes appropriate interrupt handler

BIOS sets INT2 bit at CRU >0004 for all other GPL interrupts. Or INT7 at >000E (MDOS keyboard interrupt)

BIOS branches to GPL or MDOS VDP interrupt handler for INT1 or INT7 or whatever.

 

 

etc

 

c) Sound chips. I need someone to survey WHAT software has poor hygiene around 8400. Like, writing sloppily to >8500 or >8432 that just work on the 4A. I will be mapping sound to just >8400 to >841E.

VDP, GROM etc are similarly narrowed down. 

 

d) PAD hygiene. Addresses rolling over, I think will be a problem. I assumed there was a page of RAM at >8000-9FFE. So PAD hits that from 8000 to 83FE. 1K of RAM. Except for the memory mapped ports, well, the default behavior is to see RAM at the addresses in between.  I really haven't gotten around to thinking that through--I warned you this was vague...

 

There are undoubtedly going to be problems with software. I will need others' creativity and intelligence to find those.  But, hasn't that been tried on the Geneve 9640? 

 

Finally, I think I can make a GPL that is more compatible than MDOS was.  It is certainly a necessity to have KSCAN working (by that I mean also other people's direct key scanning) because there are so many games that directly scan. Or check for FCTN QUIT or FCTN BREAK alone.  Geneve 9640 GPL couldn't do that.

 

 

 

 

 

[Myarc cards for sale/repair tips]

2 hours ago, InsaneMultitasker said:

Here is their current location on WHT, although somewhere along the line someone unpacked the ZIP I released, so it isn't obvious which files were released together: https://ftp.whtech.com/Geneve/schematics/ 

 

My concerns are two-fold: (1) the underside of the board presents pins that are nearby to one another and over the years, I have had to fix a number of Geneves where wires on the back side eventually shorted other pins, so caution must be exercised for this mod and (2) the recent question of whether the direct short was appropriate, so that the reset mod can be documented properly versus just "what might have been done back in the day". 

 

 

Those are concerning enough.

 

Today's crazy idea:

 

Use the increasingly hobbyist-friendly flex-board services. Make a flex PCB that goes under the 9995 (but above its socket), connecting to just the VCC, GND, RESET, NMI pins. All conductive traces face the plastic shell beyond that point.  Bring the flex ribbon out to the front of the card. A conventional PCB, just big enough for two buttons, is permanently mounted onto a hole in the Pbox. The flex ribbon attaches here. This tiny PCB implements a safe reset and NMI switch. 

 

 

[A few CF7+ questions]

I had that generation of CF7+. They are susceptible to static discharge. It destroys that square socketed FPGA chip. Jaime Maililong fixed mine for $20 but I last sent one in many years ago. (its dead again) You likely need that chip. 

 

I have one working CF7+. And the nanoPEB are just as vulnerable.

 

 

 

[Myarc cards for sale/repair tips]

12 minutes ago, InsaneMultitasker said:

Neat article!   If I read it correctly, the Geneve schematic shows the 9995 (and 9901) reset signal coming from the gate array.  I'm not sure what other magic the gate array is doing before it passes the reset along.  

I guess from your post about the magic keypresses, that the gate array decodes those, and pulls RESET down. 

 

Were you concerned about soldering and damaging the gate array, or just interfering with the output of the gate array? For the latter case, that limiting resistor is very wise (even 10 ohm. though I would go larger)

 

By soldering to the back of the board, even at the CPU pin, you are still going to  interfere electrically, but solder heat is much further away.

 

Now I want to know more about the schematic.

[Myarc cards for sale/repair tips]

On 11/29/2020 at 7:15 PM, webdeck said:

Okay, I tore open the PEB.  Here is a photo of the resistor.  It looks like brown, black, black, gold which means it is only 10 ohms, correct?

You want to keep that resistor. 

 

[Myarc cards for sale/repair tips]

On 11/29/2020 at 6:20 PM, InsaneMultitasker said:

Ah, gotcha.  Check continuity between the + side of C127 and 'bottom' leg of R62.  I think you'll find them connected electrically.  The spot you circle looks familiar to me as an old connection spot for the reset.  The capacitor's other lead should be connected to ground.  IIRC, using the capacitor points fell out of favor due to proximity of other through-holes and risk of future short, which morphed into using a header or direct mount switch.  

 

You can find another ground spot or use the capacitor lead as was done in the previous install.  You can also scrape off some of the foil where you mount the switch and solder directly to the ground plane.

 

If the resistor is a best practice for the reset, versus a direct 'short', I would keep it in the circuit.

 

Maybe someone with appropriate  knowledge can/will chime in on the use of the resistor in this reset application.

 

Edit: After you solder the switch into place, at minimum verify that you don't have any shorts with adjacent components or through-holes, depending on where you install it.

You don't want a direct short to ground. Putting a resistor in series, protects against a rush of current (that can exceed the rating of the el cheapo switch you got out of the bits and bobs box.)

 

https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-3/

 

Take a look at the reset switches there (there are a LOT of them but the capacitor-resistor-resistor type is adequate for the 9995 reset pin.)

 

If you want to improve on it.. put the signal through a LS14 (Buffer with Schmitt Trigger).

I spent a couple hours making a nice reset button. I thought of making it a tiny PCB, that way it could be shared.

 

[TI Related -- Ebay / Heads Up Notice]

On 11/28/2020 at 6:57 AM, dhe said:

In trying to find a piece of equipment, for a hobby unrelated to the TI. I found unlike China, there are very many products that are produced in Japan, for Japan, and there is very little interest in expanding their market oversea's. In fact it's such a big challenge, there are at least three companies in Japan, that will be your personal buyer! They check if they can get what you want, they quote you a price, you send them money, they buy the product and ship it to you.  I'm currently giving https://zenmarket.jp/ a try.

This could be very dangerous. On Saturday night, I saw a working Yamaha CX5M, bid up to a couple hundred$. I can say "no", sure sure. 

[Bringing up "Geneve 2020": Debugging Help Please!]

 

2 hours ago, pnr said:

Actually, the original Cortex did that, using a technique called "write under". Initially, reads are from ROM, but writes to the same addresses are sent to RAM. Once the copy is complete, the ROM is switched off (using a CRU bit) and both reads and writes go to RAM. There are wait states for slow ROM access.

 

Have you considered the TMS9911 DMA controller?

 

Thanks!

I did not look at the TMS9911, I assumed it would not be obtainable. I was, so far, just implementing HOLD* and HOLDA*, which could be connected to a 9911. But the 9911 fits in with "use real chips". If it's done in the FPGA, it is just a memory-to-memory block move by the DRAM controller, not access to peripherals (and the DRAM transfer would work just by generating wait states, not HOLD*). 

 

I saw something like write-under on a 6502 or Z80 forum. There was one instruction that read through whole range of addresses, perfect for caching. Need a little loop instead.

 

Write-under might not be such a stretch. I have a PLD that drives the ROM*/RAM output switch and bank bits. I could re-purpose the LED bit as the state bit. I have a spare flip-flop and LS125 tri-state gate, that could be used to generate one wait state.

 

I think I just have inputs RD* and WE* and outputs ROM OE* and RAM WE*. If it is in "write under" state, ROM OE*= RD*, and !RD* to RAM's WE*. When in "run state" it sends only RD* to RAM's OE*.

 

write under state (state=0)

ROM OE* = RD*
RAM WE* = RD*
RAM OE* = 1

 

run state (state=1)

ROM OE* = 1
RAM WE* = WE*
RAM OE* = RD*

 

I don't have to squeeze into PLD space for these--just one LS157 will do.

 

Additional logic for whether ROM or RAM page bits are on the high address lines, and RAM CE*. 

 

[Camel99 Forth Information goes here]

This is eye-popping amazing! I had never thought outside the threaded-indirect box.

 

Do I understand correctly that the output is a standalone machine language program? So if you compile in necessary utilities, it's all there? No runtime needed?

 

What happens in high-level words? When the compiler finds one, does it make a BL call? (maybe that's what the code field does? compiles a BL?)

If I write a word that contains only machine instructions, what tells the compiler whether I want it as a subroutine (with BL/RT linkage), or a new 

macro that creates machine code inline?Example

: SETVA ( address -- address )
  TOS SWPB,
  TOS 8C02 MOVB,
  TOS SWPB,
  TOS 8C02 MOVB,
;

: VSBW ( byte address -- )
  TOS 4000 ORI,
  SETVA
  DROP
  TOS 8C00 MOVB,
  DROP
;

I might want to invoke SETVA as a subroutine call sometimes, but in VSBW I want to generate those 4 instructions inline, for fastest results.

(Did I get the stack operations right?)

 

[Can an DSR ROM replace a X/BASIC CALL?]

6 hours ago, HOME AUTOMATION said:

I think there are examples of this. Though I am at a loss to recall ...Perhaps XB does this natively for some subs.

 

I was under the impression that BASIC uses the first CALL match it finds. But, scanning starts with peripheral card ROMs, than GROM bases, in reversed order.

 

However, this would seem to indicate otherwise...

 

Calling a subprogram

The calling convention is that the subprogram name (with a leading lenght byte) should be placed in VDP memory, with word >8356-57 pointing at the length byte. Then DSRLNK can be called from GPL with CALL [email protected]>0010.

• This routine first scans the peripheral card ROMs in the order if their CRU addresses, by calling XML >19.
• It then repeatedly calls XML >1A to scan the GROMs at base >9800, starting with GROM >0000, then >2000, etc upto >E000.
• It then repeats the process with bases >9804, >9808, upto >983C.

If you're curious, here is a disassembly of XML >19 and XML >1A

 

Standard headers

 

Following Thierry's excellent (as always) docs.

I didn't know any of that. Wow. 

 

[Can an DSR ROM replace a X/BASIC CALL?]

2 hours ago, jedimatt42 said:

In TI BASIC it scans Device ROMs for subprograms with every CALL before looking for built-ins. 

 

In XB, it is useless (exaggerating (tm)) as Device ROMs are only scanned in immediate mode.

Thanks. Plain ol' BASIC shines through on this one.  XB thinks it is the boss. Alas.

Maybe the DSR subprogram code couldn't work in both BASIC and XB anyhow (fetching the arguments etc).

 

 

 

Prescan: does XB prescan build a table of user-defined subprograms? I wonder if there might be some loophole there. 

 

Something like

1000 SUB SOUND(A,B,C)

1010 CALL LINK("MYCALL", "SOUND", A, B, C)

1020 SUB END

where MYCALL looks in the DSR ROMs... or just implements the darn thing that would be in the ROM

 

 

 

 

[Can an DSR ROM replace a X/BASIC CALL?]

I know that a DSR ROM can add CALLs to BASIC or XBASIC, but what happens when it provides the same name?

 

Can a DSR ROM override, say, CALL SOUND, intercepting all the calls? Or does the BASIC interpreter always take its version first?

 

Any ideas on how you could pull this off?

 

[FORTH day is today. Special guest Chuck Moore]

Here are some of my notes from the last part of FORTH day.

 

Charles H. Moore, inventor of FORTH.

Chuck Moore gave a "fireside chat". He showed us around his everyday FORTH blocks such as his dashboard, various clocks, astronomy he wants to memorize, and short quotes that give him fresh ideas.

 

Q. Could FORTH be a mainstream language like C or Java?
A. I don't think it needs to become a mainstream language.

   FORTH is a language to solve well-defined problems.
   It is a very good niche language. It is a very good tool. 
   FORTH requires the imagination, effort, and skill of a programmer.

   Always, FORTH can be used by people like us, without the world giving us permission.

Greg Bailey and Daniel Kalny of GreenArrays

 

• GreenArrays GA144 is a chip with 144 CPU nodes for running FORTH.
• Designed by Chuck Moore.
• It is not a massively parallel CPU. Each CPU is given a specific, small task.
• There is no system-wide clock. Clock distribution wastes a lot of energy. Each transition of the clock costs Vdd*C.
• When a CPU has nothing to do, it goes to sleep. Transitions take picoseconds. 
• Message passing by Ether lets CPUs send executable code+data to any other.
• Eval board has a host GA144 with complete user interface, and a target GA144.
• Pictures of how nodes are allocated to run the host software. For instance, one or more nodes for:
  •    keyboard, vga interface, GA144 programmer, at the edges of the chip.
  •    Lexical parser, number parser, word lookup, dictionary nodes.
• Best for low-power, intermittent embedded systems. For example: bridge monitoring, lasting 20 years.
• GA144 itself is designed in OKAD, in ColorFORTH. OKAD creates transistor layout by running a FORTH program.
• GLOW is also a FORTH for placing transistors and poly lines. Working to re-generate the GA144 in GLOW.
• FORTH is ideal for building up low-level components such as gates, modules, CPUs, and repeating them.
• SystemVerilog is bad at power efficiency, OKAD/GLOW is unbeatable. 

 

Links
 

http://www.greenarraychips.com/

http://etherforth.org/

http://www.greenarraychips.com/home/documents/greg/cf-intro.htm

 

 

 

 

 

 

[FORTH day is today. Special guest Chuck Moore]

Passcode is FIG

 

 

https://us02web.zoom.us/j/87480858511

 

sorry

 

[FORTH day is today. Special guest Chuck Moore]

SVFIG hosts FORTH day annually. It is today, Sat, Nov 21.   Here is the link and agenda.

All times are PST (Palo Alto, CA)

 

https://us02web.zoom.us/j/87480858511

 

900 --- Welcome --- Program Chairman Kevin Appert (5 minutes)

===========

0905 --- EForth implemented in C --- Brad Nelson (20 minutes)

An exploration of various approaches to build EForth on top of C, we'll look at variations on the core interpreter, how to populate the dictionary, X-Macros, alternate memory models, and will draw comparisons with approaches taken in cforth and gForth.

==========
0925 --- Hacking Farmer's Markets --- Mitch Bradley (20 minutes)
"By frequenting local Farmer's Markets and talking to the vendors, I have discovered a lot of need for small-scale automation. I'll show a collection of gadgets made from low-cost microprocessors, motors, sensors, and hardware store parts, with simple programming in Forth, that are a great help to small farmers and food producers."
==========
0945 --- AIBot Board Update --- Don Golding (5 minutes)

==========

0950 --- Visions of Future Forth --- Don Golding (10 minutes)

Forth has been used in both AI and space for many decades,  Forth's architecture fits perfectly for use in future space systems with low bandwidth communications links.  Incremental compilation, interpretive, extensible without a complete re-compile, can be used as a powerful terminal program for deep space robots,  You don't need to reflash the microprocessor with a large binary image over a low rate link.

==========
1000 --- Matrices In Forth --- Bill Ragsdale (20Minutes)
"I'm not sure if this has been covered over the years. The key idea is from Julian Noble's book Scientific Forth. I've got basic matrix support in 80 lines of code with lots of white space. (create, fill, list, transpose.) I can be time adjusted to your need."
==========

1020 --- A Slightly Different Forth Compiler Design --- Joseph O'Connor
(20 Minutes)
The Creole Forth compiler has several unusual features which include the lack of a STATE variable. This presentation will discuss its design features and their advantages.

==========
1040 --- Forth Challenge ... show off your solution! --- Bill Ragsdale
(duration will depend on number of presenters - reserve your spot now!)
<<Create a translator from decimal into Roman numerals from 1 to 1001. A typical demonstration would be to print: 1 to 20 and 990 to 1001. You may choose either format for numbers such as 4: IV or IIII. Note the Romans often intermixed the formats as the Colosseum uses both. See Excel's roman() function.

As a historical note, this was presented on a handout by the Forth Interest Group in their exhibit at the third West Coast Computer Faire in 1978. >>>
==========
1130 --- Forth Trivia Contest --- MC Bill Ragsdale (may run through lunch)
A trivia contest in the form of Jeopardy, really. (With the green category board and all!)
==========
1200 noon --- Virtual lunch, chat, intros, networking
==========
1230 --- Fireside Chat --- Chuck
==========
1300 --- GreenArrays Update
==========
1330 --- Programming GA144 using GA144 only --- Daniel Kalny (45 minutes)
"Chuck Moore began porting colorForth to GA144 in 2010. The project remained unfinished until 2017, when Chuck gave me his source code. Through several design iterations I finally arrived at a standalone development system for GA chips, running on a single GA144 only. In my talk I will present etherforth in its current version, and with the help of a few simple demo applications I'll show how the system works, and what kind of projects it can be used for."
 

 

[Geneve 2020 Questions and Answers!]

Hey, I welcome suggestions & feature requests! This project originates in imagination. 
 

 

15 hours ago, dhe said:

 

I've been reading the TM 990/10 docs, and it's brought up a number of questions....

 

Have you considered creating a hypervisor layer with an Arduino or pi?

Not clear exactly what you imagined? There will be a supervisor (BIOS) as that's a feature of the 99105. I understand a hypervisor to mean a manager of virtual machine containers, which boggles my mind.

 

Supervisor on the 99105 gets the first look at all interrupts. It has even more decisions to make about INT2 or MID, including dropping into the debugger. I will leave it open to forwarding to MDOS in case you set the INT2 vector there.  
 

Coprocessors are an idea I've imagined. An Arduino, ATMEGA328, is more powerful than a 99105 and doesn't seem fair. I considered a TI '430 but that's in the same class. If there's going to be a co-processor it should be a 9995. Some jobs it might do are: controlling the boot process, serial IO, disk IO.

 

 

 

15 hours ago, dhe said:

One of the nice features of the 990 chassis, was plug and pray - each slot was tied to a specific cru address, so need to set them.

Fixed CRU addresses for devices, too much of a bedrock assumption in our software.  Geneve2020 will make extensive use of byte/word-parallel CRU IO, which will add to the fixed address map! For instance, the video card can respond at memory >8C02 in GPL mode, but CRU >8C02 in BIOS mode.

 

15 hours ago, dhe said:

 

Two nice add on's that were made for the 4a, that would be nifty to build in, was Mack Mccormic published a circuit diagram when he was writing an assembly tutorial for Micropendium, that would slow down a 4a, to a craw so you could see what was happening in assembly, by playing with interrupts. The other, also interrupt focused was Jeffery Browns terminal emulator, where you programmed a non-maskable interrupt.

 

NMI is built-in. Speed control is something I've deferred, as it is a big detail-oriented job. My thinking is that the FPGA will insert wait states to match GPL speeds etc. But how many? It could add a bazillion if you like. A single-stepping debugger is a possibility--TI describes how to use NMI for single-stepping, in the University Board 990/189 coursebook/manual. Probably some other places too.

 

I'm thinking of a way to make low-level patches easy. BIOS will accept a startup script, written in FORTH (which includes the assembler). In there, you can add pretty much anything you think of. This script would typically just say BOOT-MDOS, but the possibilities are wide open. It could change the NMI behavior for instance.

 

16 hours ago, dhe said:

A Geneve is faster than a TI, a GenMod Geneve is faster than a Geneve, where do you think Geneve 2020 will fall on the speed scale if you end up using 6Mhz TMS99105's?

 

It will be faster

 

You could look at Stuart's Breadboard benchmarks for one. 

 

Keep the ideas coming!

 

 

[Disabling TI's Wait-State Generator]

8 hours ago, apersson850 said:

When I installed 64 K RAM in my console, I noticed that the warning in the E/A manual, that you need an additonal instruction, a NOP or something useful, between some VDP accesses, finally came true. For programs running from a normal memory expansion it doesn't matter. But now it did.

Only one single program I have run so far can't handle the faster memory expansion, and that's the game Tennis.

I added an LS123 timer, enabled by a CRU bit, decoded to trigger on VDP access. If I enable that, I can run Tennis in fast RAM. The computer becomes unbeatable, but the program works. Without the timer, the players, consisting of two sprites, disintegrate. The legs run in one direction and the body in another.

I too had added the NOPs (or a SWPB for VDPWA) just like it says. Until I learned from here, that unrolled loops run ok without NOP.

 

Yamaha finally added a WAIT output on the V9958, which helps solve this in hardware. Over there, it's well documented that available write slots come up with various cycles in between.

 

 

 

 

 

[TIFILES DV80 to ".txt" and back again]

6 minutes ago, InsaneMultitasker said:

@FarmerPotato - I saw your post in the Playground topic re: converting files and transferring between TI/PC.  Does your described process account for the tab character in the .txt files?   I wrote a small XB program (post #10) to properly inject spaces into my files but if another tool does this between PC<>TI that would be of benefit. 

No, unless xdm99 did something with tabs, which I doubt.

 

do you mean just changing tabs to spaces when the file is checked out? (not putting them back in?) git has a setting to do this every time.

 

do you mean the tab settings in the last line of the TI file? I forgot about those

 

[Playground]

2 hours ago, BeeryMiller said:

 

I see what you are reporting, but not being familiar with Cygwin or python, I would have never gotten there.  I'm not a linux or python user, so that is a bit beyond my skillset at the moment.  What I am hoping someone will do ( @shift838 or someone else with the skills if they are listening) will have is an installer that sets everything up on various systems (Windows a must), and then you give it a path you would like to move to<>from and it either being smart enough to do the conversion on the fly, or you tell it, and it is done from Github.

 

Simplest scenario, I launch a Windows program, point it at the TIPI for the source file directory (and potentially subdirectories).  Then, point it at Github, and necessary files move from one destination to the other with DIS/VAR 80 files converted to TXT files as needed and other formats (Program Files, others??) remaining untouched.  I think at that point, more users will feel comfortable setting things up.

 

 

 

 

You mentioned xdt - how do you launch that currently?   Python is only mentioned because XDT is written in Python and you need it to run.

 

I could make more of a step-by-step tutorial for doing this.   I do all this in Windows, after installing Cygwin tools. Cygwin installs git, python, every else needed.

 

I think I hear that you want an easy way to put Github and Tipi together, and move edits both directions from/to tipi. 

If you do all your editing on Windows, then you just need a one-way conversion, from DOS to DV80.

If you also do some editing on the TI, then you need a two-way transfer, where the DV80 is copied back to DOS text.

 

I only go one direction, from Windows to DV80. I would likely make a script on Windows/Cygwin for me. But exactly the same script would run directly on the Pi--you'd keep a ssh window logged into Pi to run it.  The script that I have (by Makefile above) only goes one way - from my source on Windows, to DV80.

 

You can use the Git GUI client on Windows to do all the github stuff. It's point and right-click to act on each file or directory.

 

 

 

 

[Playground]

22 hours ago, BeeryMiller said:

I tried another route, essentially downloading the TXT files through XMODEM which saved the files as DIS/FIX 128 since there were no TIFILES headers.  I then used a program from Al Beard, TRANSFORM, for the Geneve that would read the DIS/FIX 128 and convert to a DIS/VAR 80 file.

 

It stripped out the CR/LF issue I had, however, the labels were all screwed up and the first few lines of each file was missing.  Not sure what was going on, so that is when I went back to MyWord to find a solution.

 

We really need to find a method with some very clear step by step directions to transfer DIS/VAR 80 source up to and back down from Github without all these hurdles.  I know some have mentioned some tiimagetool (???) features, but a clear set of tool(s) to automate a single file to a hundred or more source files at a time would be an asset.  The simplest tool I could think of would be an interface function that goes talks with some tool that sends commands to GitHub to get the files, then saves the files with TIFILES headers to the TIPI.  Then, if something needed to be uploaded, it would send the other way with some method to mark directories and/or individual files.

 

I say this as there is code like FunnelWeb, MDM5, MDOS, MyWord, ABASIC, PSystem, HRD4000B+, and a host of TI-99/4A programs where this would be extremely beneficial.  Not to discourage anyone from using GitHub, but it would be very helpful if comments did not exceed past column 80 as those comments get scrolled to the next line and an assembler will want to treat it as an instruction or honk for an error.  Also, not sure whether the asterisks character is an allowable character for adding comments within the source on the xdt side of things.  I have not played with xdt to know if comments after the instruction have to be commented with the semicolon or not.  Commented source code looks great, but if comments without a semicolon is a problem for GitHub, then it really limits the ability to upload older source code. 

 

Like I said earlier, I pulled some code down from GitHub written to assemble, etc. with xdt that is not directly portable to the Geneve that I will spend several evenings porting it over into a format suitable for GenASM to process.  It's great the code was posted so don't get me wrong, however it would not be easily portable back into the Editor/Assembler assembler nor GenASM for the Geneve.

 

 

 

 

I accomplish what I need with xdm99 in the xdt package.

 

It has options to add a FIAD (your ordinary DOS text) to a TI disk image, where it appears as DV80. Then you extract it from the dsk as TIFILES. 

On the PC I keep all my version-controlled Gitlab files in DOS format. My makefile uses xdm to create a TI dsk image that has the binaries and source code, which is the distribution.

 

Here are two rules that take DOS files to TIFILES format

https://gitlab.com/FarmerPotato/gameoflife/-/blob/master/Makefile

 

LIFEO.tfi: LIFEO
	# convert to TIFILES
	$(PYTHON) $(XDM) -f DF80 -T $<

 

LIFE.tfi: LIFE
	$(PYTHON) $(XDM) -f PGM -T $<

SRCS=LIFES LIFEIMGS LIFECARTS LOADCHARS
FILES=$(TFIS) $(SRCS)

disk: $(FILES)
	$(PYTHON) $(XDM) -X 360 $(DSK) 
	$(PYTHON) $(XDM) $(DSK) -f DF80 -a LIFEO
	$(PYTHON) $(XDM) $(DSK) -f DV80 -a $(SRCS)
	$(PYTHON) $(XDM) $(DSK) -f PGM -a LIFE 

# Outputs
DSK=GAMEOFLIFE.DSK
TFIS=LIFEO.tfi LIFE.tfi

PYTHON=/usr/bin/python
XAS=/cygdrive/c/TI99/xdt99/xas99.py
XDM=/cygdrive/c/TI99/xdt99/xdm99.py

 

hmm. That represents two ways I tried to do the job. The short way is just this line, which goes from DOS, putting DV80 in the dsk:

 

$(PYTHON) $(XDM) $(DSK) -f DV80 -a $(SRCS)

 

 

I use the Cygwin utilities package, for make and python.

I unpack xdt at c:\ti99\xdt99

 

 

[Bringing up "Geneve 2020": Debugging Help Please!]

It might be the RAM is not working. I have a bigger test program that does a CRU operation early on.

 

I see the bus state is B, which is UI cycle.  I see that the red trace, ALATCH, skips a beat . That is, the CPU adds a wait state, which it does for all CRU instructions. 

 

 

If I go back a little way, I see the CPU has fetched an instruction from 0018. It writes to 8018, which is R12, then reads from 8018.

Presumably the read from 8018 is the SBZ executing and computing the address.

 

 

Here is the list file:

0018 0018 020C  20  li   r12,lights
     001A 2200     
0019 001C 1E00  20  sbz  0              led

Unfortunately, the address bus in the CRU cycle shows FFFF. Maybe the RAM is not working. (sbz should produce the address 2201. the last bit of addr is MEM which is 1. I didn't display the CRU output bit of 0 here.)

 

Something else is not working. The IO state is supposed to cause the bus signal:

 

Address   Signal

0000-7FFE SERENA*   serial CRU enable

8000-FFFE PARENA*   parallel CRU enable

 

I see neither one. 

 

 

Reviewing the schematic.. PARENA* is broken in a dumb way.

SERENA* would not activate if address is 8000 or up.

I bet that if I troubleshoot the RAM, then I will get SERENA* . but parallel CRU is broken on this version of the CPU card.

I didn't look at the RAM as much as the ROM yesterday.