Search the Community
Showing results for tags 'ASM'.
Found 4 results
I am a bloody beginner with ASM, using WUDSN IDE and MADS to code a little demo. I have an obj-soundfile which was created with "The Soundmachine" from J. Piscol, but have no idea, how to include that in my project and play it back. There is a BASIC-Demo on the Soundmachine disk, but that doesn´t help me due to my limited knowledge. Can´t find any documentation. Any help appreciated.
Hey everybody, I apologize if anyone has asked these question before -- I tried searching with limited success. I am working on writing a roguelike for the INTV, now using IntyBASIC ideally to be part of the contest. The problem is that the program I want to write, including its art assets, is kind of huge and unwieldy and I have genuine worries that I'm not going to be able to cram everything I'd like into the address space. The IntyBASIC manual has this to say about the subject: The memory_map.txt file in the SDK, however, has what appears to be a much larger selection of addresses: So, the questions I have: Does IntyBASIC attach to the areas listed in the memory map but not listed in its documentation ($4000-$4FFF, $7000-$7FFF, $8040-$9FFF) in order to store variables? What about its prologue/epilogue routines? Clearly those routines have to go somewhere, but I'm a little confused about what determines where they show up. The prologue looks like it starts at $5000 and it looks like the epilogue is using some of the address space in the $4000 block to store some routines, but is there any extra space that can be squeezed out of these areas? There is no ORG directive at the beginning of the epilogue. Do those routines just go wherever the compiler's location counter happens to be pointing when it goes to include this? Will I need to worry about the epilogue writing itself to bizarre or inappropriate places if my code stops near one of the memory boundaries, or will the BASIC compiler make sure that doesn't happen? Where is the entry point for IntyBASIC programs? I'd like to make a custom title screen if possible. If I start my program with ASM ORG $7000, will it begin execution there and bypass the EXEC? (Does IntyBASIC need the EXEC?) I noticed that there's some code at $4800 in the epilogue pertaining to the Intellivoice, but it looks like it may not be present if the Intellivoice isn't used. (I realize half the reason for using BASIC instead of assembly language is to not have to worry about fiddly details like this, but I want to make good, appropriate decisions about how to organize my program and figure out what all I will be able to include as far as assets go before I begin any major coding.) Thanks a bunch!
The "30th Lynx Birthday Compo" got me thinking of reusing the three and half shi*loads of ASM code I wrote over last few years (covering areas from point cloud, wireframe, flatshading, and many other experiments like Rez, StunRunner or StarFox). 1.VTI Spec - I spent some time googling for pdfs and specs on Lynx, but the 6 different ones I found are all missing the elusive "VTI spec" that is supposed to contain the exact cycle count of each instruction - Anybody could please upload it to this thread? 2. Additional 65C02 instructions - http://6502.org/tutorials/65c02opcodes.html lists quite a few additional instructions and addressing modes. Some are reaaally good ones and would result in much faster inner loops. - the more I look into it, the more variations of 65c02 I find with yet another 65c02 opcodes - hence the VTI spec would be really helpful to see which additional opcodes are available on Lynx's 65C02 3. Actual Frequency - Given the 16 MHz Crystal I presume the 65C02 clock in Lynx is 4.00 MHz - But all 6 docs I got use the same phrase "3.6 average". Average ? WTF ? Surely they didn't implement dynamic HW clock a century ago ? 4. Cycles available for CPU each frame - I presume Mikey is the chip that reads FrameBuffer data (160x102: 8,160 Bytes) and just like Antic on Atari 800, Mikey halts the CPU while it reads the Framebuffer data - 1 tick is 62.5 ns (1,000,000,000 / 16,000,000) - as per the doc, there's 5 ticks per read for Mikey, hence 8,160*5 = 40,800 ticks. At least. There might be dozen other things Mikey re-reads each frame (palette, etc.). - But, is it really 5 ticks ? Shouldn't it be 4 ticks for each of 256 bytes within current page and a 5 tick overhead when crossing the page boundary ? Has this been verified on HW ? - At 60 fps, there should be 266,667 Raw CPU ticks available each frame ((1,000,000,000 / 62.5) / 60) = 266,667 - Since Mikey steals at least 40,800 ticks, we should [at best] have 225,867 ticks available each frame (266,667 - 40,800) - But how much is, for example, LDA #37 ? 8 ticks, I suspect ? (4 to read opcode and 4 to read operand). Hence why VTI spec would be really helpful. 5. HW pipeline Execution time of 65C02 - I haven't found anything on this. There's 2 scenarios, though I'm heavily leaning towards the first one (it's cheaper and easier to design): - a) 65C02 behaves exactly like 6502 in this regards, regardless of frequency and, if LDA #37 takes 2 cycles on 1.79 MHz 6502, it takes same 2 cycles on 4.00 MHz 65C02. It just takes less time [in ns] on Lynx, that's all - b) 65C02 takes advantage of faster memory and higher clock, hence certain substages of the CPU decode/fetch/process pipeline execute sooner and most definitely within the cycle (impossible on 1.79 MHz), hence some instructions should be able to take less ticks 6. Suzy FrameBuffer Clear time - Anybody got timings on how much faster Suzy is in clearing FrameBuffer compared to CPU ? - Surely, the 16 MHz internal clock must fly through the FrameBuffer like a breeze, unless the internal implementation is botched. - Though, from my experience with Blitter on Jaguar, I wouldn't really be surprised if certain functionality was actually slower in the dedicated HW. I got many examples when I can beat Blitter's HW implementation with brutally hand-optimized RISC code.... 7. SW Rasterizing is barely marginally faster on Lynx than on Atari 8-bit - Upon first look, the frequency difference is 2.235x (4.00 / 1.79). Yaaay. Over twice as fast ! - But wait, 160x96 FrameBuffer on Atari is 3,840 Bytes vs 8,160 on Lynx (160x104). That's 2.125x difference (every frame, to clear framebuffer). Almost completely wiping out any frequency differential. - In flatshading, it gets even worse. On Atari 8-bit, I fill 4 pixels with one STA. On Lynx, just half. - Hence, the scanline fill will have to run exactly 2x more (e.g. 80 STAs per scanline (on Lynx) instead of 40 STAs). There goes our 2.235 speed ratio - The only advantage is, that on Lynx it will look better because we have 16 colors and not 4. - Suzy appears to have the capability of 1/2/4-bit sprite handling, but I'm not sure if CPU can directly do the same as I -yet-didn't find how to change framebuffer color bit depth to 1 or 2 bits (BPP). - I can currently think of only one type of visuals where we wouldn't be slowed down as much - Point Cloud, where it doesn't matter how many pixels are per byte, computation cost is same per pixel. Unfortunately, given the Suzy's scaling capabilities, a point cloud game on Lynx would look like Atari 2600 game on XBOX. Not worth the effort. It might look interesting (more than double the density of pixel cloud at same framerate), but that's about it. Perhaps as a loading-screen effect...
I have noticed on eBay, this Auction: Color Computer EDTASM+ Editor Assembler with ZBUG Radio Shack Tandy 26-3250 coco Would this be something "worthwhile" to purchase for the CoCo 3?? Are there any better recommendations for an Assembler Development Systems for the CoCo 3?? At this point, I have a CoCo 3 with 128K, and no Tape or Disk Interface. I am getting the DriveWire System setup on my computer, so I can work with Virtual Disk Images. The CoCo 3 is New in Box, and I am the Second Owner, the First Owner never plugged it in.. Neither have I, so I probably should.. MarkO