Jump to content

matthew180

Members
  • Content Count

    2,844
  • Joined

  • Last visited

  • Days Won

    3

matthew180 last won the day on August 13 2019

matthew180 had the most liked content!

Community Reputation

1,895 Excellent

4 Followers

About matthew180

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Castaic, California
  • Interests
    My family, FPGA, electronics, retro/vintage computers, programming, coin-op games, reading, outdoor activities.
  • Currently Playing
    Divinity2, Borderlands2, beta-testing for Realms of Antiquity (TI-99/4A CRPG).

Recent Profile Visitors

19,657 profile views
  1. Yes, that is an error in the datasheet, one of many. Just above that table, one the same page, you will see the same error in the Noise Shift Rate table. Also missing are setup-and-hold times for the CE_n, WR_n, and READY lines, no indication about the output voltage range, etc. It seems like the SN76489 datasheet was a rough draft, or was never actually finished, proof read, or edited. Yes, the "volume" is confusing since it is specified as an amount of attenuation. Basically think of the chip as being "full on", and you have to shut it up. "0000" is no attenuation, "1111" is max attenuation, but in reality it is probably transistor cut-off, which is why you see the term "OFF" in the datasheet. Also note that 2dB increments are not what people expect for audio levels. Levels that change by double or half, i.e. -/+3dB, are more typical and more what you expect to happen. 2dB steps is just odd for audio.
  2. After the random visitor today trying to get a bunch of old men excited about male organs 🤣 (WTF is wrong with people anyway?), it seems like it is time to add a password or something to the meeting? I have only been a Zoom participant, so I'm not sure if this is possible or how you would distribute the code. PM maybe?
  3. Have you tried the TMB instruction on an all zero value? Maybe it is working opposite. At least in that case it would be usable.
  4. You're probably not getting any response because the 99000 and 99105 were very late CPUs in the era, and never used in a computer that anyone here had (mostly). There are only two people in this forum that I know of who have a computer with the 99105, and that is *only* because they built that computer themselves. Since 99105 *was* used commercially, IIRC, so I'm sure its instructions work. Looking at the code, my first question is, what computer is this running on, and do you have RAM at address 1000H? The instruction: MOV R4,@BIND expects to be able to write to 1000H (the value that BIND is equated to). TMB should be testing bit 6 of with word at address 1000H, which should be FFFFH, if address 1000H is RAM. So TMB will move bit-6 of address 1000H to stats flag ST2 (equal flag), which is tested by the JEQ instruction. So I would expect the code to jump to label BIND2, where is will do whatever WHEX is on the value in R3, which is 0000H. My first instinct is, address 1000H is not RAM, so the FFFFH is not being written to it, and the data being tested by TMB is something else with bit-6 being clear.
  5. As Lee pointed out, make a pseudo stack. There was a lot of discussion about subroutine calling in the Assembly thread around here: https://atariage.com/forums/topic/162941-assembly-on-the-994a/?do=findComment&comment=2094076 Here is a skeleton I use for a pseudo stack from that thread: ** * Scratch pad RAM use - Variables * * >8300 * Workspace * >831F * Bottom of workspace STACK EQU >8320 * Subroutine stack, grows down (8 bytes) * >8322 * The stack is maintained in R10 and * >8324 * supports up to 4 BL calls * >8326 . . . * Initialize the call stack and Finite State Machine (FSM) LI R10,STACK * Set up the stack pointer . . . ********************************************************************* * * <subroutine skeleton> * SKEL MOV R11,*R10+ * Push return address onto the stack * Subroutine code here ... DECT R10 * Pop return address off the stack MOV *R10,R11 B *R11 *// SKEL
  6. The VDP Single Byte Multiple Write (VSMW) is not part of the TI provided routines. I don't know if I coined the term, but I've used it since around 2006 (or earlier) when I wrote my first pass at my own VDP routines. I don't like the routines supplied with the console, mostly because they are slow and designed for memory savings over speed. Anyway, clearing the screen, IMO, should be done directly (with the few lines of custom code that is takes), or with a VSMW-like routine. The routine is good for initializing any chuck of VRAM to a known value. I also don't like or use BLWP, I prefer to use BL. Again, these are just my personal preferences, you are welcome to use (or not) any, none, or all of this as you like. WORKSPACE EQU >8300 // Workspace, always in 16-bit scratch pad RAM * R0LB must be defined in the main assembly program to the address of * the CPU R0 LSB address. For example: R0LB EQU WORKSPACE+1 // R0 low byte, required by lib_vdp * VDP memory mapped port addresses * VDP_READ EQU >8800 // VDP read data VDP_STATUS EQU >8802 // VDP status VDP_WRITE EQU >8C00 // VDP write data VDP_ADDR EQU >8C02 // VDP set read/write address ********************************************************************* * * VDP Single Byte Multiple Write * * R0 dst: write-to address in VDP RAM * R1 src: MSB of R1 will be written to VDP RAM * R2 len: number of times to write the MSB byte of R1 to VDP RAM * * R0 is modified, but can be restored with: ANDI R0,>3FFF * R2 is changed to 0 * VSMW MOVB @R0LB,@VDP_ADDR // Send low byte of VDP RAM write address ANDI R0,>3FFF // Clear the two MSbits to 00 ORI R0,>4000 // Set read/write bits 14 and 15 to write (01) MOVB R0,@VDP_ADDR // Send high byte of VDP RAM write address VSMWLP MOVB R1,@VDP_WRITE // Write byte to VDP RAM DEC R2 // Byte counter JNE VSMWLP // Check if done B *R11 *// VSMW
  7. Here is a longer explanation about the div instruction and why certain ranges of numbers will overflow: https://atariage.com/forums/topic/162941-assembly-on-the-994a/?do=findComment&comment=2732413 Basically if you use the 9900 divide as a 16-bit by 16-bit divide, it will always work as expected. As soon as you use a dividend larger than 16-bits, you have to pay attention.
  8. It is because the division is really a 32-bit value divided by a 16-bit value, and the answer has to fit in a 16-bit quotient and 16-bit remainder. The dividend (number being divided) is 32-bit, and the divisor is 16-bit. The rule is, the divisor must be greater-than the most-significant 16-bit word of the dividend. 5 / 5 should be fine. Did you try it? What will not work is something like: 0x8FFFF / 0x4, since the answer quotient will not fit in the 16-bit result.
  9. Oh there was plenty of that, being a sailor and all.
  10. It is assumed that once a program unlocks the F18A then it is "F18A aware", and therefore the program knows it will have new features to deal with, like sprites enabled in the text modes. However, the F18A *does* try to have sensible defaults, so there should not be too much extra to deal with. Sprites being disabled is one of those extra details, since disabling them depends on the sprite attribute table in VRAM, and not VDP registers. Yes, as Rasmus mentioned, writing to VR50 will reset the F18A's default power-on register values and relocks the F18A. Note that the palette registers are *not* reset. I do not know why TI BASIC would be garbled with the F18A unlocked. The default register values are designed to keep the F18A looking like the 9918A until they are changed. However, there is a *LOT* of bad software out there, which is why I had to incorporate locking the F18A in the first place. The problem is that the VDP register to write is specified with 6-bits (10 RRR RRR) of the byte written to the VDP. The 9918A would just ignore the top 3-bits of the 6-bits (and the datasheet specifies they are to be zero), so only VR0..VR7 can be specified. When the F18A is locked it does the same thing. However, when the F18A is unlocked, all 6-bits are used to specify the additional VDP registers, i.e. VR0..VR63 (not all exist, but many do). In a lot of legacy software, there is junk (due to sloppy coding) in the 3 extra bits that are usually ignored, however they cannot be ignored by the F18A when it is unlocked. So when such software is run on an unlocked F18A (or 9938/59, which do not have a lock feature) it will cause all kinds of problems. It took me a long time to figure this out when testing the F18A, and I have found offensive software on *all* systems that use the 9918A VDP. So basically, any legacy software that writes to VDP registers over VR7 will have negative consequences when the F18A is unlocked. I do not know specifically if TI BASIC in an offender, but it would not surprise me if it is. The VGA pig-tail that comes with the F18A is not the greatest quality (they were the best I could find), and the wires inside the VGA shell break easily. The shell slides easily down the ribbon cable, so you should be able to inspect and repair any broken wires.
  11. @Cobalt Tiger The MK2 is not done yet. When they are available, you will be able to purchase them from my web store, and possibly other places (undetermined at this time). Update: I have spent the better part of the last 3 to 4 weeks working (fighting, pulling of hair, crying, etc.) on the digital video output, and I finally have it working and tested. I am now able to work on decoupling the scan-line generation from the pixel scan-out, which is required to support the digital video, and was also a not-so-good design on my part. Since much of the HDL was created while I was also learning VHDL and FPGAs, a lot of design decisions were made with limited knowledge and information, and some of the design needs to change so I can advance the HDL for the MK2 features. I am trying to keep the changes limited to the essentials so I can get the MK2 out as quickly as possible, with future updates planned.
  12. The two in the U.S. were $17 and $30. Hard cover though, and very good condition. While that was more than I wanted to spend on a 35 year old book, I also like having a physical copy, and the information cannot go out of date.
  13. I'm going to be a pessimist and say "lack of foresight". The "home computer" was probably not intended to have that much memory, otherwise it might complete with the minicomputer (oh no, computers are advancing!?!?) Laying-out a memory-map in chunks of 8K seemed to be very popular at the time, based on other systems I have looked at of the same era. The memory-map for the first 32K goes: ROM, Cartridge, Devices (DSR ROMs), memory-mapped devices. Maybe having the top 32K as RAM expansion *was* always in the design though, but only the 99/4A designers could say for sure. But not having RAM in the console, other than the 256-bytes of 16-bit scratchpad... That's the worse design decision IMO. It would have been nice if they had put the 8K of Cartridge space up at >8000, which would have made it contiguous with the 32K RAM expansion. And it would also have been nice if they had made the >8000 range less wasted and provided a way to expand the 256-bytes of 16-bit RAM. Or, at least further decoded the >8000 block into 1K blocks; but that would have taken another 74LS138 3-to-8 decoder IC and cost $1.50 more... GASP! Also, having RAM in the ISR vector memory space would have been a *very* useful design decision. But, knowing why does not change how it is, and sadly making a new system in the spirit of the 99/4A is still not going to be a 99/4A in the end.
  14. That is ok, continuing older threads is not a problem on this forum, and IIRC we like this better (at least I do) than starting a new thread with the same or similar topic. Long-running conversations make the forum, and life, more interesting. That is very cool; and welcome! There are a lot of people here, myself included, that really enjoy hearing from the people who were "there" and involved in the history of our retro-computer of choice. That is really fun (and helpful) to know! I don't know if this information was commonly known (I suspect some people here might know this), but it is new information to me. Thanks. Thanks for the reference, I just ordered one (used) from Amazon. Walter Triebel seems to have written quite a few books on various CPUs during the 80's and early 90's.
  15. The F18A MK1 has no external RAM since the Spartan-3E 250 FPGA has 24K or Block-RAM, which was enough for the 16K of original VDP RAM, plus line buffers and GPU-only RAM. The F18A design makes extensive use of the dual-port capability of the FPGA's Block-RAM, and if a target FPGA does not have dual-port Block-RAM I don't think you would get the F18A ported, short of a complete rewrite. I was also a little wasteful with Block-RAM use in the MK1, since I did not think to expand the VRAM to something like 20K (I still need line buffers). That mistake is going to cost me dearly in the near future. The MK2 will introduce a lot of change in the design, since it does have 512K of external RAM. However, even though the external SRAM is fast (10ns), it does not have the dual-port capability of the FPGA's internal Block-RAM, so the memory timing on the MK2 is going to get a lot more complicated and things are going to get tight.
×
×
  • Create New...