Jump to content

matthew180

Members
  • Content Count

    2,738
  • Joined

  • Last visited

  • Days Won

    3

matthew180 last won the day on August 13 2019

matthew180 had the most liked content!

Community Reputation

1,591 Excellent

2 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
    With my son: Divinity2, Borderlands, TorchLight2. With the family: Minecraft

Recent Profile Visitors

19,075 profile views
  1. I know this is not an answer to the question, and falls into the kind of response I personally don't like (when people question the reason for doing something in the first place, rather than trying to help with a solution). But, I'll ask anyway, but mostly just out of curiosity: Why not just manage the handful of variables needed to allow your code handle both 40 and 80 columns at run time? This would allow you to make selecting 40/80 columns at runtime, and you only have one code-base and final executable to manage. The answer "because I don't want to" is perfectly acceptable. 🙂
  2. If the assembler generates the correct opcode, then it is tested. It is mostly a bunch of consecutive address records, which does not make sense. The code seems to be missing: 0 0020 32 bytes of code, no IDT A 0004 load address 0004 A 0006 load address 0006 A 0006 load address 0006 B 0000 absolute data A 0008 load address 0008 B FF00 asbolute data A 0009 load address 0009 7 F681 checksum F end of record 7 FFC9 checksum F end of record : The closest code I could come up with is: AORG >0006 DATA >0000 BYTE >FF Not must of a program.
  3. Ralph, I was just reading the xdt99 docs and saw the support for the F18A instructions, very cool! xas99 supports the F18A GPU instruction set. CALL <gas> RET PUSH <gas> POP <gad> SLC <wa>, <count> PIC <gas>, <gad> I just two notes: 1. The Pixel instruction is called PIX (not PIC) and is a re-purposing of the XOP instruction (you probably know that). 2. The GPU also utilizes the 9900 IDLE instruction (I'm not sure if xdt99 already supports that opcode or not?)
  4. You can also do this to make it a little more readable: IDLE_OP EQU >0340 . . . DATA IDLE_OP If the assembler had full MACRO support you could do the whole "DATA >0340" as IDLE_OP. Either way, I also recommend using the XDT99 tools: https://atariage.com/forums/topic/233677-xdt99-new-ti-99-cross-development-tools-available/
  5. Yes, you could do that. The 2K of GPU-only RAM is just that, RAM, but only the GPU in the F18A can address it; meaning you cannot access this RAM via the VDP address-pointer used by the host CPU to access normal VRAM. You have to use the GPU to move data between this RAM and normal VRAM. This limitation is because the GPU has a real 16-bit address bus, and the VRAM address-pointer is only 14-bit. Also keep in mind that the changes coming in the MK2 are going to change this. Really the GPU RAM is handy for GPU subroutines, exactly like you described. If you make a GPU line draw routine (using the PIX instruction to make it really fast), then you could certainly load pairs of xy line coordinates into VRAM and trigger the GPU routine to process the list. Rasmus may have already written such a routine, and you should definitely check out his F18A demos (easiest way is via his js99er browser-based emulator). The F18A has a DMA engine that can copy or fill blocks of memory, so yes, the DMA can do a fill operation instead of a copy. It can also move forwards or backwards through VRAM. Each read/write operation takes 20ns, so the entire 16K VRAM could be processed in 327.6us. The 768 byte name table can be moved in 15.3us, and a 2K pattern table could be cleared in 40.9us. Here is a summary of the DMA registers: * >6000 to >603F VDP regs * * The DMA src, dst, width, height, stride are copied to dedicated counters when * the DMA is triggered, thus the original values remain unchanged. NTBA EQU >6002 ; Name table base address DMA_SRC EQU >8000 ; DMA 16-bit src address, MSB first DMA_DST EQU >8002 ; DMA 16-bit dst address, MSB first DMA_W EQU >8004 ; DMA width DMA_H EQU >8005 ; DMA height DMA_STRIDE EQU >8006 ; DMA stride DMA_CMD EQU >8007 ; DMA command: 0..5 | !INC/DEC | !COPY/FILL DMA_TRIG EQU >8008 ; DMA trigger, write any value to address The addresses of these registers are available only via the GPU. Using the DMA is non-destructive these registers, so once set up it can be triggered multiple times using the same parameters (if you need to do the same operation multiple times, i.e. always clearing or copying a block of memory, etc.) The F18A Programming and Resources thread in the 99/4A dev sub-forum has a lot of the features documented. I'm working on getting proper docs written in one place, but until then, asking questions is the best way to get the info. Here is a port where I show how to use the GPU to do the name-table block moves to assist with scrolling: https://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/?do=findComment&comment=3604629
  6. Sorry for being late to the thread, I tend to try and limit my attention these days so I can focus on getting the MK2 done. My thoughts as I read through the thread: The MK2 is going to force some changes since it has 512K of VRAM. Not that this will help the existing F18A, but I am working on changes that will hopefully free up an additional 4K of Block RAM in the FPGA (by not being so greedy with line buffers), which I can make available as VRAM for the current F18A. So a total of 20K instead of 16K. The private 2K of GPU-only RAM will probably become part of that 20K. If I can get 20K of VRAM, this should help make it possible to double-buffer a pattern table or the bitmap layer, so you will have a full frame to draw the next frame, instead of only the vsync period. The GPU runs at the internal 100MHz clock, but takes multiple cycles per instruction. You can assume an average of 250ns per instruction when memory-to-memory operations are used. The GPU has full 16-bit read/write access to VRAM as well as the palette registers and general VDP registers. The GPU can easily respond to the horizontal interrupt, or just spin and watch for a certain scan line if you need such capability. If you use the BML (bitmap layer), as Tursi mentioned, the GPU has a dedicated "PIX" (pixel) instruction that can read/modify/write a pixel based on X,Y coordinates. There is no faster way to write pixels since all the calculations are done in hardware and the actual VRAM update happens in 10ns (although the entire instruction takes several cycles). The PIX instruction can also partially operate in GM2 mode by performing the calculation to find the correct byte and bit to update for a pixel. The GPU also has a block move processor that can copy bytes of VRAM at 10ns per byte. You absolutely cannot get faster access to VRAM. I realize this does not do much for pixel processing since there is no pixel-per-byte mode, but it can speed up things like clearing large sections of VRAM, shifting the name table to support horizontal and vertical scrolling, etc. You can change the VRAM address pointer's auto-increment value from -128 to +127 (signed byte). So you can do stride-based VRAM access. Helps do horizontal scrolling of the name-table, for example, if you don't use the GPU. I don't like "modes", so aside from the modes that are part of the original VDP, i.e. GM1, GM2, T40, etc. you will find that most of the features in the F18A are more like "layers", and can be used in any "mode". For example, the BML is not a "mode", you just turn it on, so it can be used in any mode. Same with sprites, once the F18A is unlocked, sprites are available in all the "modes", and can be used at the same time as the BML. Tile Layer 2 (TL2) is probably the only enhancement that was intended to be used in GM1 mode. Sprites and tiles can have their own ECM level, so if you don't need ECM3 for tiles, you can use ECM2 and save some VRAM. Sprites can also have their own size, per-sprite, as well as flip-x, and flip-y, to try and help save pattern VRAM. You can limit the number of patterns available to sprites and tile, so the size of the pattern tables can be reduced if you don't need all 256 patterns. The reduction in size is by powers of 2, so 256, 128, 64, 32. Can be huge VRAM savings if you manage patterns carefully. There has been a lot of discussion in the 99/4A subsection about doing vector type graphics and such. If you have not frequented the 99/4A dev sub-forum on these topics, you might want to see what Rasmus and others have discussed and tried.
  7. #1 rule for rework: Desoldering is twice as hard as soldering. The vacuum-powered desolder tools are generally well worth the money if you use them enough (which is what makes their high cost a hard decision to make for a hobbyist). Like arcadeshopper, I spent the money on a Hakko FR-300 some years ago, and I'm very glad to have it for DIP rework. But it is a single-task tool, so for me it does not get used much. I also find that you have to be very careful with it since it gets very hot and can easily dump too much heat into a pad and even damage the PCB substrate. The more professional vacuum stations are the next step up from the hand-held ones. Going the in the cheaper direction are the manual pumps and the heated gizmos with the air-bulb on them, both of which I have used, and neither of which I would recommend. A good hot-air rework station will go a long way these days. Also, ChipQuik. The #2 rule of rework: keep everything (tips, surfaces, parts, etc.) clean and use a good no-clean flux!
  8. I use my 99/4A primarily to test hardware I'm making. One day I would like to have one all put together and set up for general use. One day...
  9. Getting started depends on where you are coming from. If you need to also learn all the assembly prerequisites at the same time, i.e. binary, hex, understanding memory, I/O vs memory-map, addressing modes, etc. then the approach will certainly be different. All CPUs and computers work pretty much the same way, so a lot of concepts will apply no matter where you learn them or what system you are working on. After that, you have the specifics of the CPU and architecture of the computer you have chosen. For the 99/4A, working in an emulator will make your experience much more pleasant, IMO. Real hardware is good for testing and running your software, play games and *using* software, showing off to your friends and family, and for a trip down memory lane to experience editing and assembling like we used to do it (but only for 5 minutes ). But of learning and development, emulation all the way. An emulator also gives you the benefit of a level of debugging that you simply cannot get on real hardware. My go-to development emulators are Classic99 and JS99er coupled with the XDT99 compiler tools (see the Development Resources thread in the forum). It really helps to have a bunch of small programs you want to write, which will help guide your learning. Keep in mind that you don't have to understand everything when you are starting off, and you probably won't. Understanding comes over time, but it is very important to be able to write working code from day-1 to keep up your enthusiasm and motivation. Simple programs are things like clearing the screen, some basic character animation like moving something across the screen, etc. Leave things like speech synthesis until later, since in assembly it takes a lot of code and data to get this working, and it is easy to get very lost (IMO). Even doing sound can be somewhat of a more complex topic when getting started because it relies on changing data at a "human" pace rather than as-fast-as the computer can execute instructions. This means you need to have a concept of timing, which on the 99/4A there are multiple options, each with benefits and trade-offs (like most things). The E/A Manual is a decent reference that coves a lot of material in a non-beginner kind of way, however to its credit is does clearly state: "This manual assumes that you already know a programming language, preferably an assembly language. If you do not, there are many fine books available which teach the basics of assembly language use. After you know these basics, this manual gives the details of TMS9900 assembly language and its application to the TI Home Computer." I agree with that statement 100%. When I started learning assembly as a teen in '83, the E/A manual was all I had at first and there was much frustration, hair-pulling, and probably even some tears of anger. It was not until I found the book "COMPUTE!'s beginner's guide to assembly language on the TI-99/4A" by Peter Lottrup that I was able to actually start writing my own programs and get an understanding of how the computer worked and what was going on. However, even though Lottrup's book opened the door to assembly for me, it does stay at a higher level of assembly on the 99/4A (which can be great for getting started). However, even more important than books, I would say this forum and code-reading are the best resources for learning and answers. Having an understanding of what a compiler, assembler, and linker do will also help greatly. Beyond that, get comfortable with hex and binary, and start writing "clear screen" followed by "move @". 🙂 Ask questions and put in the effort to try and find answers on your own. Most importantly though, have fun, enjoy the journey, and allow yourself the time to learn; because it will take time.
  10. V1.9 is the latest and fixes a timing bug that has been in the design since its inception. See the first post the F18A Resources thread: https://atariage.com/forums/topic/207586-f18a-programming-info-and-resources/ There is an in-system updater for the 99/4A and ColecoVision. If the FG99 can help with that in some way, I don't know (don't have one, never used it, not paying very good attention these days).
  11. My dad had a TI-57 (or 58 or 59, I can't remember), and one day he gave me a booklet with some example programs, and I seem to remember entering in a Lunar Lander type game on it. This was in the late 70's, maybe even 1980 or 1981. It was my dad's familiarity with TI that made him choose the 99/4A over the C64 one fateful day at JC-Penny in 1982.
  12. One black, one white Nintendo DSi (with stylus-izs... ), one charger, carrying case and 5 games: Pokemon HeartGold, Pokemon SoulSilver, Super Mario Bros., Metal Slug 7, and Nintendogs. Units are in good shape and all buttons work. See photos, ask questions. Not sure what I want for them, best fair offer gets the lot. Matthew
  13. Thanks for the update. I think balancing is probably one of the hardest aspects of an RPG. Get it wrong and people will consider the game too hard or too easy, and overall not be happy with it. I also imagine implementing a difficulty system would be, uh, difficult (no pun intended) too. But, even if the balancing is off in some places, what people won't forgive are bugs that crash or dump you out of the game right after something like a really hard battle, etc. Anyway, I'm looking forward to the release.
  14. So how is the beta testing going? No pressure, just excited to give it a whirl. I'm curious to see if I can entice my teenager son to stop shooting things in Destiny2 and giving this game a try.
×
×
  • Create New...