FarmerPotato

When the CPU reads from the cartridge port, what do the data lines look like on the side port? I think the cartridge port data lines and side port data lines are the same wire. This could be read by a sideport peripheral connected directly to the data bus -- but not by a Pbox card where there are LS245 buffers in the flex cable and the card itself. I'm imagining the CPU reading from >6000 and expecting to find >AA. A really smart sideport peripheral would detect the first read cycle on that address, monitor the data bus to see if the cartridge ROM supplies >AA, and stand down. Or discover what happens when it contends for the data bus This doesn't solve contention in the case that you want the sideport ROM to be there at startup. By the time the smart peripheral waits to see if the cartridge responds, it will be too late for it to supply a byte. So it would fail to be included in the cartridge menu scan. It would apply in the case where SAMS is told to map into the cartridge space after startup. I don't really see a sensible use case here, unless this imaginary sidecar device provides a menu loader in addition to a cartridge library, and you don't ever exoect to plug in a cartridge like E/A or XB. Just an idea. Supposing a more sophisticated future SAMS implementation,

My first paying job was reclaiming 4116 RAM chips at a recycling shop during the 1988 price spike. Old boards would come in, go through a hot plate, hundreds of random chips would be dumped on my desk. I picked out all the 4116s or better, straightened the pins, put them in tubes, and they sold immediately to assembly shops to go back into memory boards. All the other chips (74LS etc) went on the retail shelf untested. I picked out some nice looking 6802, 8008 etc. Straightening 4116 pins kept me in enough work hours (at minimum wage) to buy a Geneve 9640. I maintained inventory and price lists in Wordstar for CP/M, on a machine that was spared from recycling. (We also saved a Sol-1 which I kick myself for not taking home.)

I searched in other forums: Atari 8-bit board, Sophia Rev C 2018, has DVI out: http://atariage.com/forums/topic/274004-sophia-revc-dvi-board/ They use a ribbon cable to a board with DVI socket.

I got the Samsung Syncmaster 910MP from the May eBay auction. This is the one with SCART, VGA, AV inputs. It's DOA. The menu functions all work. It detects my F18A VGA input as 640x480 32.3 kHz NN (matching what another Samsung VGA monitor detects.) However, in PC mode it is all black. Same result for other VGA sources so it's not the F18A. In AV mode it has a static filled black and white image (from composite.) I have ordered a re-cap kit for it. When that's in hand I'll open up the 910MP for inspection. Any other advice on what to look for?

Thanks for verifying these timings. I was especially interested in what you observed for the sound chip. One detail some might want elaborated: When the sound chip SN76489 takes READY low for 32 of its cycles, those are counted at 3.579MHz, or the equivalent of 26.76 cpu cycles at 3 MHz. Tursi recorded 27 cycles, and I guess sometimes plus one?

I am excited that not only are we getting F18As, but a ton of unexpected bonuses too! I pledged to buy 5 of them to boost the order, I'm still going to. I use my good F18A console for everything. I hope we can share good solutions to mounting an HDMI port on the plastic.

Here's a utility I threw together to read .DSK files - it compiles under Cygwin and probably plenty of other environments. I needed it to quickly catalog disks that I was scanning with Kryoflux, and also used it to dump out some files or read FORTH screens. https://github.com/olsone/forti/blob/master/tidir.c $ ./tidir.exe mati00053.dsk File size is 92160 DSK.00053 Free= 160 Used= 200 9S,40T,1S,1D FDR Name Size Type P Sector(Offset) --- ---------- ---- ----------- - -------------- 2 BOOT 21 Dis/Var 80 223001 22(13) 3 BOOTBJ 6 Dis/Fix 80 364000 36(4) 4 DRIVER 98 Dis/Var 80 3b0006 3b(60) 5 UTILEQU 3 Dis/Var 80 9c1000 9c(1) 6 UTILRAM 4 Dis/Var 80 9e2000 9e(2) 7 UTILROM 48 Dis/Var 80 a1e002 a1(2e) $ ./tidir.exe mati00053.dsk DRIVER > driver.txt $ more.driver.txt TITL 'FORTH DRIVER WITH UTIL' IDT 'FORTH' ************************************************************ TEMP0 EQU 0 TEMP1 EQU 1 $ ./tidir.exe mati00053.dsk DRIVER > driver.txt

The Magic Wand Speaking Reader indeed required the iron ink (as in check printing.) This made the sensor durable. A version of the Magic Wand which uses a red LED laser scanner exists. It can work from any photocopied material and read Magic Wand books. Also, an interface between the Magic Wand and the TI-99/4A joystick/cassette ports was made, with which the 4A could send commands and allophone strings for speaking. This was for testing the MWSR, not expanding the 4A, since the 4A with a speech synthesizer and TE2 was just as capable.

Oh crud... I referred my brother to chaser2015 to unload some unloved 4A items, in Colorado Springs. Something wasn't quite right about his enthusiastic response to common items. Fortunately chaser2015 didn't follow up. We will avoid this person.

The sound chip has a 10 bit counter value N. It can be from 0 to 1023. The math is: frequency = 111860.8 / N. This number is scaled down from the VDP crystal at 3.57955 MHz. The reproducible values include f=109.3458 Hz at N=1023, the lowest it can go. f=109.99 Hz at N=1017, the "textbook" (Editor/Assembler) value for low A. f=110.099 Hz at N=1016, a low A that is adjusted to tune with A440. f=329.0023 Hz at N=340 f=329.9728 Hz at N=339 f=330.9491 Hz at N=338 f=438.6697 Hz at N=255 f=440.3968 Hz at N=254 I haven't checked which way TI BASIC might round the value from CALL SOUND, but I chose my frequency values to match integer values of N. I got the theory wrong before my experiment. Here is the right experiment to do around f=330: 10 CALL SOUND(2000, 109.99, 0, 330.9491, 10) 20 PRINT "BEAT" 30 CALL SOUND(2000, 109.99, 0, 329.9728, 10) 40 PRINT "NO BEAT" 50 GOTO 10 Sure enough, there it is. There's the beat! But it doesn't support my hypothesis that A110 should be retuned to match A440.

The other day I noticed that the E/A sound table for A440 implied a SLIGHTLY out of tune A110. The "Textbook" values for the sound chip are 3F9 and 0FE producing 109.99 and 440.3968 Hz. If tuning the low A to match, you choose 3F8 to produce 110.1 instead. What's the difference? Well, when two notes are played together, and one is out of tune, you hear a beat sensation. The "beat" is the two frequencies interfering constructively and destructively. Try this: (in TI BASIC for everyone following at home) 10 CALL SOUND(4000, 109.99, 0, 110.4, 0) 20 GOTO 10 or this: 30 CALL SOUND(4000, 440.3968, 0, 438.67, 0) 40 GOTO 30 RUN 30 It's actually a cool sound effect that you will recognize from Munch Man. You can hear the beat take place at f1-f2, which is 0.4 Hz in the first example, more like 2 Hz in the second. A square wave (the kind the 76489 sound chip can generate) is composed of a fundamental frequency plus the odd harmonics at 1/n. That is, a square wave at 110 contains f=110 plus f=440 at 1/3 or -10dB. (EDIT: no it doesn't, it's at f=330. My article falls apart here.) Given f=109.99, the third harmonic is at 439.96 (EDIT: no, it's 330), but when playing A440, the closest the sound chip can get is either 438.67 or 440.3968. The chord A110+A440.3968 should give us a chance to hear a beat at 0.4 Hz. It should go away when the low A is tuned to 110.1. I wonder if you can hear this beat in the 3rd harmonic: 10 CALL SOUND(2000, 109.99, 0, 440.3867, 10) 20 PRINT "BEAT" 30 CALL SOUND(2000, 110.1, 0, 440.3867, 10) 40 PRINT "NO BEAT" 50 GOTO 10 I think I can hear one? I can tell that the low A is moving a tiny bit, but the beat should have a quality like the first example of a 0.4 Hz beat. I think that I hear a beat at about 3 Hz on both of them. Not sure what's up with that. Caveat: I did these tests on Classic99. I got out a 4A console to test real hardware, but a 4116 memory chip failed spectacularly. I'll write elsewhere of the joy of [email protected] HNRTRTLDNTR and playing [email protected] [email protected] and TH [email protected]

I need to interpolate smoothly between notes, i.e. generate notes that are not in the table. I haven't posted that code yet.

I like the idea of choosing a f(clk) that is a multiple of 440. The important thing is that the periods produced are in neat integer ratios. I notice for the first time that TI's periods for As are not: 3F9, 1FC, FE, 7F, 40. The period FE produces a frequency 440.3968 Hz, so TI's choice of >3f9 or 109.999 Hz is inferior to using >3F8 or 110.099 Hz. At the other end, 1760 Hz is approximated by >40 or 1747 Hz in the TI table but I would prefer to err sharp with >3F for 1775.57 Hz. 109.999 vs 110.099 -- is it too small to matter? The 3rd harmonic (recall a square wave is composed of only odd harmonics) is 439.996 Hz vs 440.396 Hz. Since we are centered on 440.3968 Hz, the TI (lower) choice should create a beat frequency at 0.4 Hz in the 3rd harmonic when notes with periods 3F9 and FE are played together. Should be detectable by ear. I'm going to check how that sounds on real hardware later on. (Aside: I just got a large pile of SN76496 from China.) So, I like your As. There are not "musically perfect" frequencies. It is up the orchestra. Historically, the frequency of A varied quite a bit. That said, in the group I performed with for many years, our piano accompanist had "perfect pitch", was also married to the conductor, and would single out anybody who was singing off pitch. Also, you are starting with integer frequencies, so in addition to tuning up the As, you could pay similar attention to precision on other notes. Best, -Erik Why are orchestras tuned differently?

That's weird. SOCB is the wrong thing to do (it is bitwise OR). Because TOS already holds C0AB you should get CCAB. Are you sure you didn't make a typo when putting in your machine code? (I saw earlier you were putting in machine code D108 for MOVB W,TOS) (On a side note, SZCB is next in my bag of tricks after SRC but I couldn't find a way to use it here.) Here's my log of running the version I gave you on Sunday. (under TI FORTH it trashes R8 .) D586 0B44 src R4,4 (24) D588 C204 mov R4,R8 (18) 42 D58A 0948 srl R8,4 (24) 66 D58C D108 movb R8,R4 (18) 84 D58E 045F b *R15 (16) Here's my working TI FORTH version and test results. Of course TI FORTH doesn't have the TOS optimization, only SP. I have to copy *SP to R1 instead since SRC can't do indirect addressing.. CODE XS SP *? 1 MOV, 1 4 SRC, 1 SP *? MOV, 1 4 SRL, 1 SP *? MOVB, NEXT, ( Classic99) D586 C059 mov *R9,R1 (26) 26 D588 0B41 src R1,4 (24) 50 D58A C641 mov R1,*R9 (30) 80 D58C 0941 srl R1,4 (24) 104 D58E D641 movb R1,*R9 (30) 134 D590 045F b *R15 (16) 150 ( Test) 0ABC XS U. CAB ok 00FE XS U. E0F ok ( Cycles Camel FORTH 24 + 18 + 24 + 18 TI FORTH 26 + 24 + 30 + 24 + 30 ) I think I need the optimization more than you, since I do this bit twiddling (and its reverse) inside the interrupt routine to interpolate frequencies, but so far you only use it at compile time. I can see how much the TOS optimization is worth in Camel Forth: 4 instructions in 84 cycles, vs 5 instructions in 134 cycles in TI FORTH. An extra MOV to get *SP and 12 cycles each for indirect register access. I didn't count the NEXT, Best, -Erik

Rounding can be something like this: ( d1 n1 -- d1+n1/2 n1) ( add 1/2 n1 to d1. kludge, ignores overflow) : +F2/ ROT OVER 2 / + ROT ROT ;

The advantage of doing everything in the interrupt service routine is precise timing. The console sound list format uses a number of ticks (1/60th seconds) to idle before loading the next group of bytes. Alternately, in a game you might have the ISR just decrement some timers. Then the main game loop checks the timers, pushes sound bytes, moves sprites, etc. In FORTI the MUSIC ISR plays in the background so that, naturally, you can keep programming (or fiddling with the music by changing the tempo variable.) You might want to add nearest rounding to HZ>CODE. The sound cmd byte table in the E/A manual incorporates rounding. For instance, 110 Hz is N=1016.916 or 1017 and the code is 093F. Your code rounds toward 0 and gives 093E. That makes a bias toward sharp. The error is 1% by the time you get to D#6 at 1244.51 Hz, where rounding down gives 1256.86 Hz. But that's inconsequential. Interestingly, a real piano is tuned sharp in that octave, but for reasons that don't apply here. (In physical strings, harmonics of A3 tend sharp, so A6 is tuned sharp to match.) For comparison, here is the table from FORTI. It uses the rounded values. ( A+) 93F , 03C , A38 , 735 , 732 , A2F , ( 110) ( D#) F2C , 72A , 128 , D25 , B23 , B21 , ( A ) C1F , 01E , 51C , C1A , 419 , D17 , ( 220) ( D#) 816 , 315 , 014 , E12 , D11 , D10 , ( A ) E0F , 00F , 20E , 60D , A0C , E0B , ( 440) ( D#) 40B , A0A , 00A , 709 , F08 , 708 , ( A ) F07 , 807 , 107 , B06 , 506 , F05 , ( 880) ( D#) A05 , 505 , 005 , C04 , 704 , 304 , ( A ) 004 , C03 , 903 , 503 , 203 , 003 , ( 1760) ( D#) D02 , A02 , 802 , 602 , 402 , 202 , Main thread for that is May the FORTH Musical offering - FORTI Decompiled

"Math on the interval" Problem statement: Given the cmd bytes for a tone, generate a table that varies the frequency between plus/minus one half step. I'll post my solution later. In brief, I interpolate between two interval (period register) values. A list of sound chip command bytes is created when a note begins and sent to the chip on 1/60th sec ticks.

I have a similar problem (math on the interval) so I looked at this in detail. If TOS is just a register as you say, TOS 4 SRC, TOS W MOV, W 4 SRL, W TOS MOVB, Classic99 reports 114 cycles for your version, 84 for this. Tips: W SWPB, is faster than W 8 SLA, When you need to operate on the LSB, and you know the WP, skip the SWPB for a tiny improvement 8317 @() TOS AB, Shifts won't work if TOS needs to be *SP. FORTH assembler will happily take SP *? 4 SRC, but it isn't detected as an out of bounds condition and produces SP 5 SRC, Best, -Erik

Ok here is the 99/4 BASIC bug: 10 CALL EDIT 10 10 CALL CLEAR PRINT CHR$(7) LIST 1 EDIT 1 1 REM * spectacular VDP RAM trashing* severity seems to depend on whether there was prior stuff in ram. I seem to recall the 99/4 Errata sheet describes it as: "The computer may lock up when, after editing a line, entering a Statement Used As A Command". (As we say now, Challenge accepted!) I tried this in Classic99. I did not see it drop back into a BASIC prompt in 2-3 minutes, like I recall it doing. Classic99 reports lots of illegal VDP register writes. If it scrambles VDP registers really badly, the next Cold Reset doesn't fix them, and the title screen is garbage.

You have to edit line 10 after doing a PRINT command. Change it or erase it I'll test it on hardware again I don't suppose the Ti-99/4 errata sheet is scanned somewhere?

If I make it on time (driving from Seattle that day) I will show my FORTI software, but in Classic99 emulation on my laptop. I'm unsure whether to bring hardware that is not ready, but if I do I would sure appreciate your input. -Erik

I would not suggest breaking things permanently. I prefer it to be settable in Options (like many Win32 programs have an Options page for mapping hotkeys to functions.)

Hi, Some love for SAMS. I am working on the FORTI reimplementation and I frequently run out of memory. Fortunately there is good support for compiling into SAMS memory in TurboForth and fbFORTH. I'm using TI FORTH (the original environment) but planning to target fbFORTH. The real trick is having the interrupt service routine get sound data from SAMS pages. I plan to support a SAMS option in my software release (for unmodified 4A with no FORTI card, just one sound chip). AND then I wired up 256k of SAMS memory on my prototype FORTI hardware, so it is kind of a mini-SAMS sound card. I'll see if that flies. Probably won't do that in a PBOX card though. -Erik

Hey! I've been using Classic99 heavily. Thanks for an awesome tool! I've been evaluating all the disks I scan with Kryoflux, and doing a lot of FORTH development. 1. I use Paste a lot to paste into the FORTH prompt. Can I request a keyboard shortcut for Paste? (ctrl-V or something not to interfere with the 4A keyboard) 2. My wishlist would also include a Copy function that grabs the VDP screen table with line breaks. I guess I could get that from a VDP dump... 3. I messed with the CLIP device as a replacement for RS232 in the FORTH SWCH word. The SWCH word redirects character I/O to a file (user variable ALTOUT can be any PAB). However FORTH then writes 1 char per record. CLIP adds a newline after each record, so it's a tall skinny file with 4 blank lines where FORTH sends a CRLF to the printer. I cleaned it up with a script, but it seems convoluted. Does Classic99 have a RS232 DSR somewhere?

In 1986 I wrote to Yamaha to ask for a evaluation sample of the 9938. They sent me the chip. The pin spacing, 1.778mm or 0.07" stumped me. How to put it into a perfboard? I had never made a PCB, only wire wrap and solder. I called the US electronics distributors and no one had the socket for it. A helpful TI engineer heard of my difficulty. He brought me a big 64 pin 0.1" machined pin socket (TMS9900 style), and a piece of balsa wood. He wire wrapped 64 little wires onto the 9938 pins, glued it onto the balsa block, and left me to solder the wires to the socket holes. I hot glued two rows of wire wrap headers onto my perfboard, to create a socket for the 64 pin socket. It almost worked, even. It passed read/write memory tests with a pair of 4464s. Unfortunately I didn't know enough about the external circuitry to make the picture stable. I still have that 9938 beast in my parts box. Then I got a Geneve and just used that... Much love for that chip.