FarmerPotato

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.

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!

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? 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.

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)

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. 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. 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.

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.

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.

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.

You want to keep that resistor.

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.

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.

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*.

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?)

Following Thierry's excellent (as always) docs. I didn't know any of that. Wow.

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

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?

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

Passcode is FIG https://us02web.zoom.us/j/87480858511 sorry

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."

Hey, I welcome suggestions & feature requests! This project originates in imagination. 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. 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. 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. It will be faster You could look at Stuart's Breadboard benchmarks for one. Keep the ideas coming!

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.

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

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.

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

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.