Jump to content

FarmerPotato

+AtariAge Subscriber
  • Content Count

    1,464
  • Joined

  • Last visited

Posts posted by FarmerPotato


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

    • Like 2

  2.  

    I am not sure why you interpolate frequencies in the interrupt routine, when you know the frequency of each note before hand. But I have not looked at you code beyond a quick scan so what do I know.

     

     

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


  3. So after looking at your table I realized I could solve this the other way around.

     

    Given f=440 and the correct command byte=>FE, what should f(clk) be?

     

    The answer is 111,760 Hz. So I changed that value and my 440 is a real A. And octaves sound more in tune now albeit not musically perfect.

     

    So by fudging the clock frequency I get better command byte values.

     

    If I am correct your values will generate the tempered scale and mine are the mathematical values, correct at 440Hz and drifting off of musical values at the low and high end.

     

    For my technical lexicon consisting of Hz and dB commands this is fine.

    For my music player I am going to switch everything to your values.

     

    For comparison:

    ( A+) 93F , ( 110)

    ( A ) C1F , ( 220)

    ( A ) E0F , ( 440)

    ( A ) F07 , ( 880)

    ( A ) 004 , ( 1760)

     

     

    B

     

     

    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

  4.  

     

    BTW I found that the above did not work for 440Hz. while testing.

    Instead E0F as the cmd bytes I got 00F.

    I cannot understand why? (I have not doubled check this finding)

     

    It seems to work with this change:

     CODE >FCODE ( 0abc -- 0cab) \ version by Farmer Potato Atariage
                  TOS 4 SRC,   \ C0AB
                  TOS W MOV,   \ DUP
                  W 4 SRL,     \ 0C0A
                  W TOS SOCB,  \ 0CAB
                NEXT,          
                ENDCODE
    
    

     

    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

     


  5.  

    Ah yes. I am very interested in that.

     

    My solution is pretty simple, I take the frequency of the oscillator as a 32bit integer and divide it by the audio frequency and now I use your improved code to roll the nibbles into the command bytes.

    Looks like this at the moment. My oscillator is off by .8 Hz at the moment, but it still makes music that sounds in tune over a couple of octaves or so.

     

    With your help it now looks like this:

    DECIMAL
     : f(clk) ( -- d)  46324 1  ;   \ this is 111,860 as 32 bit int.
    
    CODE >FCODE ( 0abc -- 0cab) \ version by Farmer Potato Atariage
                0B44 ,          \ TOS 4 SRC,   \ C0AB
                0948 ,          \ TOS W MOV,   \ DUP
                0948 ,          \ W 4 SRL,     \ 0C0A
                D108 ,          \ W TOS MOVB,  \ 0CAB
                NEXT,           \ 8 BYTES, 28 uS :-)
                ENDCODE
    
    \ convert freq. to 9919 chip code
    : HZ>CODE  ( freq -- fcode ) f(clk) ROT UM/MOD NIP >FCODE ;
    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

     


  6.  

    From the above comments:

     

    Please explain "math on the interval"

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

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

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

    • Like 1

  9.  

     

    Any agenda anyone attending wants anyone else attending to be prepared for?

     

    If I'm lucky I'll have a TIPI-PEB card in hand that works. It is more likely I'll have one in hand that doesn't work ( the current state )

     

    [email protected]

     

    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


  10.  

    Please do not change that. That would break the “forward-word-tab” function of the TI Forth and fbForth block editors.

     

    ...lee

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

    • Like 2

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


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

    • Like 1

  13. Wow! Looks like there isn't much in the way of supporting the TIM upgrade on new designs. I've poured over the datasheet numerous times.

    I see a V9958, the full compliment of 128KB DRAM, a counter, and the faster crystal. I thought I did read the pin spacing was changed to an odd .09" (and of course pin functions) to make it not "drop in" compatible which explains the daughter card.

    Also, I have never seen a real-life picture of the SOB before. Read about it, but's about it.

    Thank you!

     

    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.

    • Like 4

  14. Unisource was the one selling Exceltek cartridges--and interestingly enough, they were listed as being released by Sunware in their Encyclopedic catalog. I just received a copy of that catalog this month (prior to that all I had were a couple of the pricing supplements to it). It lists quite a few cartridges, actually (there are about 20 in total, most of them extremely rare with an Exceltek label). I have Stargazer I, Killer Caterpillar, Arcturus, Extended BASIC, and I think one other. I also have a Sunware released cartridge.

    I appreciate learning anything about Exceltec.
    Unisource was a computer store in Lubbock, TX that flourished from 1983-1986. They sold TI-99/4A and C-64 and others.
    I first saw Micropendium there. I never had the mail order catalog because I rode my bike over there. It was the place to go to see exciting stuff like SuperSketch and the MBX.
    Sunware had an office a short distance away, in Pyramid Plaza Office Building. The pyramid itself was a sight. The TI West building was also nearby. I first saw the Sunware name placard while going upstairs to a restaurant that had an Omega Race video game (my kid brain was wired like a squirrel to recall all the arcade game locations).
    The rumor was that some of the best TI game programmers were working at Sunware after TI. It was a mysterious place.
    I played a Sunware Space Patrol cartridge at a friend's house (when it was still Sunware.) I think it came from the Unisource store.
    I wanted to publish Bubble Plane as a cartridge, and got an informal meeting with a Sunware employee. I was trying out an Extended Basic compiler and didn't know if that would ever work out to make a game into a cartridge (no). I was told to come back when I had an all assembly language game. I also saw the Love Tennis game (I didn't admit I'd already seen a leaked copy.) Years later I really finished my game, using the Geneve to emulate bank switching for 32k cartridge (8k game + 24k graphics and level data). I didn't know how to get it published.
    Unisource was in the news after a burglary in 1985. At the same time, multiple Corcomp 9900 MPES + dual floppy were offered for sale on a local bulletin board, cheap, $200 with printer. I persuaded my brother to buy one. My TI-Net BBS was developed on one MPES, and run on another one. I have a strong suspicion that the MPES was fenced. The seller, we'll call him Frank, was briefly enthusiastic about using the TI-99/4A and getting software to other new users. Then Frank abruptly left town, still owing my brother $60 for selling the printer to someone else.
    -Erik
    • Like 3


  15. Challenge:


    Write a description of an original TI-99/4A game that you would mashup with another game. The mashup game will use characters and game play from BOTH games.


    Example:


    Cars and Carcasses and Katamari


    In this update of a 1982 Not-Polyoptics game, you are trapped in a car in a graveyard full of zombies, vampires, and Frankenstein's monsters. You must run them over, while not crashing into any tombstones, until your car grows into a sticky ball of monster carcasses, capable of rolling over everything in its path.


    Clarification:


    You don't have to write the game, only imagine it!


    Prizes:


    We all win.



  16. Alternate titles I've considered for this topic are:

     

    Undeveloped TI BASIC feature?

    Tokens in TI BASIC?

    Sprites in TI BASIC.

    Fault prediction results

    Failure analysis experiments

    Keyword entry feature

     

    Anyway, going way back, it seems like I became intrigued with finding oversights in games, software, hardware and systems. Such as the trick in Donkey Kong where you can trap the fires by jumping over a peg as the fire passes under you. The Pac-Man trick where you eat a blue monster as it emerges form the center box, causing it to go off the map, than eating it again traping its "spirit" in a loop. The "hiding" places where the monsters can't find you, ever. Many phone hacks, etc.

     

    My first TI 99/4a was a floor model, bought for me on X-mas eve, it was the last one, as I was told. Price $1000. The store made them sign a no-refund disclaimer, saying that it was a prototype. Though it did seem to run all software, in some ways it differed slightly. I clearly recall the title screen copyright 1979.

     

    String variables Such as: A$="full four lines of text", if concatenated as such: B$=A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$&A$"

     

    typing PRINT B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$&B$ from immediate mode(not in a program), would print out proceedurally until fully complete, possibly locking the user out for hours or even days if a third string is assigned. I could not duplicate this behavior on any other TI.

     

    O.K. now that the preamble is over!

     

    By trying many unlikely things, I discovered that typing control or undefined function keys in a REM statement from TI BASIC causes RESERVED WORDS to print out if the program line is LISTED. Some of the function keys cause strange character sequences to print, with long delays in between(FCTN V,?).

     

    Some reserved words, such as RANDOMIZE (CTRL U) are long enough that attempting to edit a full four line entry of them, results in a single program line, that is longer than the screen table, apparently causing an overwrite of VDP tables and perhaps causing BASIC to alter VDP registers as well. While entering chars on such a long line, sprites appear at times, also the screen can loose horizontal sync, probably from external video being activated (this will cause newer monitors to cut out).

    If Function 1 (del) is the first key edit, the entire screen scrolls left! using FUNCTION 2 (ins) and entering full lenth edits can cause basic to become crazy, returning messages such as *BAD NAME IN LINE NUMER 44736(RUN), trying to RESEQUENCE such a program causes a strange pattern lockup.

    Here is a related anomaly in TI-99/4 BASIC
    10 CALL CLEAR
    PRINT CHR$(7)
    EDIT 10
    10
    The bug was documented as using a "statement used as a command" then editing a line.
    TI inserted an ERRATA sheet into the 99/4 packing, practically daring you to try it.
    The effect was that the entire contents of VDP RAM was shifted down by 1 byte. I can
    understand this in terms of TI BASIC compacting the program in VDP RAM, moving everything up 1 byte, counting down the addresses, but the start address is corrupt and the process goes on and on.
    First there is a delay.
    Then you observe the pattern table shifting down 1 pixel row. All the visible chars drop one pixel lower, but not all at the same time. It's slow enough for you to have a thought that your program is gone and memory is being trashed.
    Then the screen fills with sprites and gibberish, and the really bad stuff begins.
    Yes, decrementing the VDP address below 0 means it is time to write random values
    into the VDP registers!
    LI R0,>FFFF
    SWPB R0
    MOVB R0,@>8C02
    SWPB R0
    MOVB R0,@>8C02
    DEC R0
    JMP $-14
    Yikes!
    On a TV output, this means the screen begins to "tear". There are seconds of darkness, then a flash of bright white, followed by pulses of distorted video between which fragments of your program are briefly visible. There is an audible whine from the television set as the video signal pushes it beyond its comfort envelope.
    In my 8 year old mind this was what FUBAR meant.
    However, after a time, the madness ceases. The blackness is still. There is a softly blinking spot. The cursor is back! You press enter; nothing improves. You make a syntax error, and the screen is somewhat restored.
    If you are lucky, there are sprites, which you can play with by typing under them.
    Just don't type LIST, or the horror may begin all over again. The cursed number 32767 may appear.
    I still feel a fricasee of dread when I cross its path.
    • Like 3

  17. Funny thing, when I read your reply the part # is coverd by a solid color. only by selecting line the can I read the #.

    I would go on to blow 2 more of these I.C.s out in different TI/994As and in very unique incidents (RATS!).

    One I replaced with a 76489. All the tones were much lower in frequency. Not good as I used lm567n PLLs to decode the TI's high frequencies to run a small matrix of relays. I learned why recently. I think I learned it here on atariage possibly from Fabrice. Excellent!

    The older chips accepted a clock frequency of 447 KHz:

    TMS9919
    SN94624
    SN76494
    These all have an internal clock divider of 2. The TI-99/4A had an external 74LS161 to divide the VDP clock 3.579 MHz by 8.
    For external sales (saving a part cost), TI incorporated the divider into the chip in these parts:
    SN76489 uses 3.579545 MHz internally dividing by 16.
    SN76489A
    SN76496 differs in that it also has an AUDIO IN
    If you put an SN76489A in an older console, it would technically be out of spec, but if it worked at all you would get much lower frequencies (extra divide by 8).
    I'm double checking all these details again tomorrow, as I've received a batch of SN76489A from China for FORTI card builds and I'm going to leave out the external divider.
    • Like 2

  18. Thank you for the comments. I am continuing to work on this. I will have a source code update next weekend.

    In the absence of a copy of the actual FORTI distribution disk (D), here is my plan:

    Road Map for FORTI

    Clean source (compilable) for (B) Bach Demo and © Chariots of Fire, Ricercar a 8. Including some defining word features implemented to match (D)

    FORTH assembler version of MUSIC, as well as CODE version (machine code)

    Full implementation of features of (D) from user manual, with some innovations.

    Collection of Bach inventions and sinfonias for 2-3 voices

    MIDI import tool

    TRON arcade game music (originally used AY-8910)

    Well-known TI game songs remixed

    Tool to export compiled music as A/L source for use outside FORTH

    Reference release (E) (Erik) with innovations

    4-chip FORTI card PCB (not made yet)

    Extra special music card project compatible with FORTI (hardware built! waiting while I do software)

    Major musical work demo

    MIDI player

    Speech synthesizer integration

    Animatronic art installation

    • Like 4

  19. Since Extended Basic just sets error to 130 meaning I/O ERROR, I think you have to retrieve the error byte from the PAB in VDP.

     

    I've never done this from Basic, but here is a beginning:

     

    Theory

     

    This would apply if the file were still open (no help with a DELETE statement!)

    Start with the PAB list. Get the 2 bytes at CPU address >833C (Somebody shoot me if I'm wrong. I'm just reading the docs for the first time since Craig Miller covered XB VDP memory in detail in Smart Programmer.)

    http://www.unige.ch/medecine/nouspikel/ti99/vdpram.htm

    That gives you a VDP address to start looking at. The VDP memory contains a linked list:

     

    2 bytes: next PAB's VDP address or 0

    1 byte: file number

    1 byte: hmm

    10 bytes: PAB with length byte at byte 9

    N bytes: filename

     

     

    If the IO error was for a file # that is still open, there would be a PAB entry for it. Assuming you had CALL PEEKV.. (probably you get your own and write CALL LINK("PEEKV", A,B,C,D ) etc

     

    CALL PEEK(-31940, A, B)

    V = A*256+B

     

    CALL PEEKV(V, A, B)

    V2 = A*256+B

    CALL PEEKV(V+2, FILENUM)

     

    Inside the PAB structure, byte 0 is the operaton and byte 1 contains the error code (upper 3 bits).

    http://www.unige.ch/medecine/nouspikel/ti99/headers.htm#PAB

    CALL PEEKV(V+4, A, B)

    E = A*10+INT(B/32)

     

    E would be your I/O Error code.

     

    I don't think there's anything in that table for a DELETE statement that doesn't keep an open file, so no juice. But I think this is the answer for a file that is still open.

     

    TEST

     


    So I tried this
    10 ON ERROR 50
    20 DELETE "DSK2.HHHH"
    30 END
    50 CALL ERR(A,B)
    60 PRINT A,B
    70 GOTO 70
    Without the ON ERROR I get I/O ERROR 73.
    Poking around at runtime, I find a likely PAB at VDP >37A9. It starts with 07 60 which is the opcode DELETE and error bits 011 or 3.
    The length byte is at >37B2
    Size of PAB is 10 + 9 for the filename which makes the next VDP address >37BC

    I looked for anything in CPU RAM pointing to those addresses. Nope. I guess though that this is inside the String Space.. Basic made a temporary string allocation and then freed it? I'm not sure.

     

    Now I want to know the answers!

    • Like 1

  20. Here is a photo of mine. It shows 4x 2564s with date code 8327 for 32k and 2x 6116 RAMs for 4k

    IMG 8899

    IMG 8900

    .

    Thank you FarmerPotato to answering the call. Sure, A dump of your 99/2 ROM set would be interesting :-)
    Can you describe in details the trouble on your 99/2? Maybe we can revive it!

    • Like 2

  21. Can you describe in details the trouble on your 99/2? Maybe we can revive it!

    It has not powered up. I do not see full voltage on the power brick, with no load, so that may be the issue (it is just a linear transformer in there?)

    I don't have a bench power supply.

     

    I purchased a LCR meter so I'm going to start checking components. Starting with the big capacitor.


  22. If we resume the 99/2 ROM sets dumped, we have the ones of Klaus and I, do we have another one?

    Hi 99/2 owners,

     

    I've been following this thread eagerly.

     

    I have a 99/2, though it stopped working some years ago. It looks to have 32K ROM after piggy-backing a 2564 (28 pin) with some Kynar wiring. I have a plan to dump the ROMS in-circuit if I can't power it up.

    • Like 2
×
×
  • Create New...