Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Stuart

Members
 View Profile  See their activity

  • Content Count

    1,020

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Stuart

  2. Posted

    Hi all,

    I need some support too.

    Since nearly three months I'm back in my TI-Hobby after about 30 years.

    I bought some additional Hardware like a FG99, a Speech Synthesizer and a nanoPEB and tried some old programs I have in TI-Basic and XB.

    All works fine. Now I did a small XB program to manage my nanoPEB volumes for different Environments. It's a simpl menue with include the disk catalog and Mount the volumes I Need for TI-Basic, XB, TI-Writer and E/A....

    When I start my program in TI Basic all works fine. If I start the program in XB the catalog part works, but all parts with the command MOUNT(X,Y) do not work.

    From XB I get the message "Subprogram Not Found in XXXX". If I try in Command Mode from the XB prompt Mount(X,Y) works.

    Do you have any suggestions for me?

     

    CALL MOUNT won't work inside a program, as others have said. But have a look at this page [http://gtello.pagesperso-orange.fr/ti99_e.htm] and there's a program you can use to switch volumes within a program. Scroll down that page to the picture of the NanoPEB and that's where the details are.

    • Like 1

  4. Posted

    Should work OK.

     

    "Loading/saving from/to disk is now supported using standard device/file names in quotes (for example, SAVE "DSK3.MYPROG" and LOAD "DSK3.MYPROG"). The auto-run feature as described in the Cortex user guide is also supported. Note though that I think the system crashes at the moment if you try to save a file with the same name as an existing file."

    • Like 1

  5. Posted

    HELP. Yeah, I forgot all my electronics training from HS and I can't seem to understand things I'm searching for. Use it or lose it they say. they are correct.

     

    I purchase a box of assorted LEDs and misread the labels when i ordered. I thought I was ordering assorted 3v and 6v LEDS but that's not the case.

    all the LEDs are max ratings of 2.2V or 3.2V when i actually needed 5V LEDs so I'm trying to figure out how to lower the voltage from 5V to 3V in-line.

     

    I thought this might be the solution but they are talking current and not voltage, I'm unsure of the current I'm dealing with.

     

    http://www.instructables.com/topics/How-to-change-5v-into-3v-using-only-resistors/

     

     

    Use this: http://led.linear1.org/1led.wiz (which is linked to from that link you provided).

     

    There are three numbers involved:

     

    (1) The voltage you're driving the LED from. So this is 5V if you're connecting the LED + series resistor across a 5V power supply.

     

    (2) The forward voltage of the LED - this is your 2.2V or 3.3V.

     

    (3) The current through the LED - you can get this from the LED datasheet but 20mA is usually an approx. value. The higher the current the brighter the LED.

     

    For a 5V supply, you'll probably need a resistor in the range 100 - 300 Ohms approx. An alternative way to do it is to get a 'resistor selection pack' that covers that range, and starting with a 300 Ohm resistor try consecutively lower values until the LED achieves the brightness you want. You may find that the resistor value recommended by a 'series resistor calculator' is either too bright or not bright enough anyway, and you want to nudge up or down to the next resistor value.

    • Like 2

  7. Posted

    @Stuart: I'm pretty sure that the WAV file behind that link does have the 713E bug:

     

    Hmmm ... that's very strange. I can't test the .wav easily without getting lots of things out of cupboards and soldering up an audio cable. All the LBLA listings I have use the >718E value. I'm starting to wonder if I was actually given that .wav file by someone else, and they had a dodgy tape ...

  8. Posted

     

    So this confirms that mizapf and I have buggy copies. It's unlikely that they both are result of tape corruption. More probably TI issued a batch of tapes with a buggy version of LBLA

     

    So can you patch those addresses in Easy Bug, save it back to a new tape, and see if it then works as it should? (Although there may of course be differences elsewhere in the code.)

     

    There's a .wav file of the 'good' version at http://www.stuartconner.me.uk/ti/cassette_wavs/lbla.wav if you have the means of playing that into your TI.

  10. Posted

    To confirm the way it should work: do NEW and it should start assembling at >7D00. Enter a few instructions and labels, then SYM to check the symbol table, then END to return to the MiniMem screen. Then OLD and it will briefly flash a message about the number of unresolved references (it's not meant to do this - it's just the way it clears the screen buffer) and then show the address after the last instruction entered (with previous instructions being retained). If you then do SYM it should show the symbol table from the previous session.

     

    If you're losing the symbol table and the location counter is >7F00 - what address range are you assembling at? Wondering if you could be overwriting some of the LBLA data? What happens if you assemble just a few instructions at >7D00? You're NOT powering off between the NEW and OLD sessions (just in case the cartridge battery is flat and you're losing some data from the RAM)?

     

    Also note that there is a bug in the LBLA which can affect instructions with two symbolic addressing operands. See http://www.stuartconner.me.uk/ti/ti.htm#minimem_lbla_bug for the details and a fix.

  12. Posted

    Hi, can the experienced programmers confirm if the following statements are true and I understood the topics correct?

    The background is that I am working on a tool TIcode99 and would like to get it reading in 99xx(x) source code files correct.

     

    Special operand types [CruBit <cnt>, Xop <xop>, ShiftCount <scnt>]

     

    - If an opcode requires a numeric input for an operand, the sourcecode can define the number as decimal or hexadecimal.

    >>> Depends on the assembler. No reason it couldn't be binary or octal if the assembler supports it.

     

    - If an opcode requires a numeric input for an operand, the sourcecode can always define a symbol (EQU opcode) and refer the symbol name instead of a direct numeric input

    >>> Correct.

     

    - If an opcode requires a numeric input for an operand, the sourcecode can refer a Workspace Register instead (like 'SLA R5,R0'). However not the value of the Workspace Register is used but the number of the Workspace Register

    >>> The register values R0 to R15 are normally EQU'd as values 0 to 15 (that's one of the assembly options in EA IIRC; EA works fine specifying a register as just the register value). So "SLA R5,R0" would be assembled as "SLA R5,0". (As an aside, the register value doesn't need to be R(anything); if you had a program where the X position of something was stored in R2 and the Y position in R3, you could define symbols XPOS EQU 2 and YPOS EQU 3 and use instructions like "SLA XPOS,2" and "SLA YPOS,4".)

     

    - for these operand types I can not use '1+2' as operand.

    >>> No reason why not if the assembler supports it. It simply calculates the expression before assembling the instruction.

     

    Immediate operand type <iop>

     

    - If I define a Symbol, I can refer the symbol as immediate operand. Here I can also use a symbol reference like below to define an immediate operand.

    >>> Yep. Although I think EA requires the first example below to be "0-SYMB1". SDSMAC (I think) is happy with just "-SYMB1".

    -SYMB1
SYMB1+2
SYMB1*256
SYMB1+SYMB2

    All of these examples don't work for the operand types CruBit <cnt>, Xop <xop>, ShiftCount <scnt>.

    >>> No reason why not if the assembler supports it. It simply calculates the expression before assembling the instruction.

     

    - Below instruction is not supported on the TI-99 Editor Assembler, but probably on the TI-990 Assembler (SDSMAC).

    >>> IIRC EA doesn't support the parantheses? So would have to write as >F*4+MF1? Certainly wouldn't be >FFFF - it would be the arithmetic product >F*4.

     LI   R1,MF1+(>F*4)

    I assume it can be translated to?

    LI   R1,MF1+>FFFF

    Questions about the Immediate Operand type:

     

    1. What does this instruction mean?

    >>> If this was code destined for SDSMAC, I think it is less 'fussy' over the use of "@" - you can tell from the instruction whether it should be an immediate operand. I comment on this a bit further down.

    CI   R0,@ENDDAT
...
ENDDAT EQU $

    It fails for me in the EA, never the less the 99/8 source code uses such code in DEBUGG.

     

    Other example:

    PAR02   CI   R8,@INTEG$*256
...
INTEG$ EQU  >AE

    2. How can a String be useful as immediate Value?

    >>> Uses the ASCII value of the character. So for example you have a keyboard scanning routine that places the ASCII value of the key pressed in the LSB of R2. The instruction CI R2,'A' will test if the 'A' key was pressed. If the key value is stored in the MSB of R2, then use CI R2,'A'*256 - multiplying by 256 puts the ASCII value of "A" in the MSB of the word. (Haven't seen a string value with two characters before - presumably 'AB' puts the ASCII value for 'A' in the MSB and the ASCII value for 'B' in the LSB.)

    'E'
'I'-'0'
-'0'
'--'
'-'*256

    I don't understand the usecase when to use a String like shown as Immediate operand. How are these "translated" into a numeric value?

     

    Symbol operand type <symbol>

     

    This operand type is a bit unclear to me. Afaik this i used by opcodes DEF, REF, SREF, LOAD, DXOP, END and DFOP.

    Should this solely allow the definition/reference of a symbol?

    Or should I be able to use something like "SYMB1+2" or other 'expressions'?

     

    Workspace operand type <wa>

    XPTL   EQU  6
SRL  XPTL,8

    Since this works, it seems I can use a Symbol instead of a direct reference of one of the Workspace Register. Is it translated to Shift R6 by 8 to the right?

    >>> Yep, commented on this above.

     

    However I can not use "XPTL+2" for that operand.

    >>> No reason why not if the assembler supports it. "XPTL+2" would resolve to R8.

     

    Expression operand type <exp>

     

    It is quite clear that wherever the syntax definitions says here should be an <exp> as operand type it allows an expression to be used. However it seems that the Immediate operand type <iop> and the General Address operand types <gas>,<gad> are heavily using expressions as well.

     

    Is the assumption correct, that every expression has to result in some number (address) during assembling time?

    >>> Yep.

     

    General operand type <gas>, <gad>

     

    I see sometimes an operand looking like indexed memory addressing, however the @ sign is not there.

    WRTADD   EQU      >402
...
         MOVB      R4,WRTADD(R9)

    Any explanations on why this is missing the @ sign?

    >>> As I commented above, SDSMAC (I think) is less 'fussy' over the need for the @, as it can be inferred from the instruction. In the source for the disk version of TI Invaders which I assume was assembled by SDSMAC, there are a few instructions like MOVB @H00,HERE, and it presumably assembled OK.

     

    Many thanks for your help in advance.

     

     

    I've tried to put some answers in-line above, prefixed with >>>.

  15. Posted

    (Major digression - here's a chap who apparently helped to design the 9911 - https://www.linkedin.com/in/longley/. He also claims to have done the product definition for the TMS9909 floppy disk controller, and that that chip was in full production for 8 years. For a chip that was produced for so long, it is mighty hard to get hold of one, and I don't think anyone has seen one that isn't the 'TMX' prototype version.)

  16. Posted

    Looks like the TI documentation is inconsistent with regards what's required. There's an example diagram in the 9900 data manual (as you say) with a pair of cascaded 74148's with no synchronisation. The 74148 was also sold as the TIM9907, and looking on the page for that in the Microsystems Designers handbook there's an application diagram showing a 74148 connected to a 9900, and preceded by a LS373 latch clocked by phase 3 clock. Right beside it there's a 74148 connected to a 9980/9981 with no latch. If you're using a 9901, then they are latched in that.

  17. Posted

     

    I took a quick look at the object file, but it does not quite match the memory contents of the MM after LBLA is loaded and I can't seem to find the right string to change in it. I do know however that the file represents the entire 4K of the MM from >7000 to >7FFF, so it will likely be just a matter of counting bytes as long as I understand how the file is formatted. I see that each line is terminated by 80000F. Is that correct?

     

    I've attached a corrected version.

    MM_LBLA_CORRECTED.rar

    • Like 1

  18. Posted

    Well I've got another one for you...

    It appears that the LBLA does not like doing operations between 2 addresses symbolically. For example, the instruction C @X1,@X2 where X1 and X2 are labels to single words does not work. Neither does A @X1,@X2. Replacing one of the labels with the direct address or a register solves the problem.

    Is this normal? I don't recall coming across that issue before with the EA...

     

    That's a bug in LBLA. See [http://www.stuartconner.me.uk/ti/ti.htm#minimem_lbla_bug].

  20. Posted

    Hooray, some progress!

     

    If the card is at CRU >1000, then try the XB program again but in line 20 change the *fourth* number from 17 to 16 (this number determines which CRU address is accessed). When you run the XB program the LED on the card should flash - but it may be so brief that you don't see it.

     

    If you've got a bad EPROM socket then that is very likely to be the problem. You may well find that it bursts into life when the socket is repaired/replaced.

     

    Looking at which ICs are socketed, you've got the EPROMs and PALs that will be programmed and fitted to the card after it has been manufactured, and the 9901 and FDC which, although not *expected* to fail, are perhaps the most likely to have failed if the card develops a problem. And/or fault-finding a hardware problem on the card is easier if these ICs can be removed (without damaging them).

    • Like 1

  22. Posted

    I'd like to sound out opinions on a new sub-forum for TMS99xx development that is not directly related to the TI-99/4A.

     

    Potentially to cover single-board or breadboard systems like those I've produced, the Powertran Cortex and Mini-Cortex designs, and there are a couple of people doing some interesting development using the TMS99110. It would be handy to have a forum for discussions rather than using e-mail that some of us are currently using.

     

    We already have a few topics for this in the TI-99/4A Development subforum but it tends to get swamped by the TI-99 stuff, and there are probably enough TI-99 enthusiasts interested in other TMS99xx development that having it as a sub-forum (rather than somewhere else completely - not on AtariAge) is a good idea.

     

    Thoughts?

    • Like 2

  23. Posted

     

    There was nothing but ZEROS, and, DOTS, when I tried that XB program, and, I will try the minimem "trick" again, but, I was wondering if I should go "bare minimum" on what is in the P-Box, when I try various other "DSR"

    viewing commands? Won't that "contaminate" the other cards...(ie. RS232, 32k, ect...).

     

     

    Yes, take everything else out of the PBOX before trying to access the card at other addresses.

  24. Posted · Edited by Stuart

    Hey All! :-)

     

    Well...I tried both; The Mini-Memory "trick" and the XB "trick". Both worked!...for my "functional, no-problem-at-all" TI FDC... with the CC FDC, ...nothing worked. I tried the Mini-mem test first...didn't even light up the LED on the card , when I did "C1100 1"...

    With the XB, I just kept getting error notifications, every time I tried to run the program.

    So...I'm guessing it IS the circuitry of the CC FDC that is completely unuseable. I was truly wondering if anyone has seen this kind of "Mod" before, in a CC FDC ?

     

    Sincerely...

     

    Jt

     

    What XB error did you get with the CC card? Even if the card is duff, I would expect the XB program to still run but return a load of 0 values.

     

    Is the function of the DIL switches documented anywhere? I would have expected the MiniMem trick to be able to switch on the card LED (as you say it blinks when trying to access the floppies from BASIC) unless one of the DIL switches is changing the CRU address away from the standard >1100 for an FDC card. You might want to try the MiniMem trick again but try different addresses C1000, C1100 (you tried that already), C1200, C1300, C1400 up to C1F00 and see if any of those light the LED.

     

    I wouldn't be too worried about the mod to the crystal yet. The crystal only provides a clock for the floppy controller IC, let's see if we can read the EPROMs first.

  25. Posted

     

    In my case, computer won't even start. However, I can dump the ROM's with my chip burner and see what comes out of that.

     

    Do you think the trick with turning on the PEB, after the console, work? I can test this theory later, for grins. But I'll trust my chip burner dump over a software one any day.

     

    Cheers!

     

    I don't think the XB program will work in that case unless you have 32K RAM in the console - ISTR that the XB CALL INIT won't work unless 32K RAM was available at boot time. But if you have a MiniMem cartridge you can use the MiniMem trick referenced in the link, or if you have one of the 64/128K ROM cartridge boards then burn my Mini Memory Line-By-Line Assembler, TIBUG and Disassembler cartridge (http://www.stuartconner.me.uk/ti/ti.htm#minimem_lbla_tibug_disassembler_cartridge) and use TIBUG instead of the MiniMem EasyBug.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...