Jump to content

oziphantom

New Members
  • Posts

    33
  • Joined

  • Last visited

Profile Information

  • Custom Status
    Lost
  • Gender
    Male
  • Location
    Commodore Ivory Tower

oziphantom's Achievements

Space Invader

Space Invader (2/9)

2

Reputation

  1. ASSEMbler is a forum of people who have and collect devkits. But seeing as we have two copies of the "docs" here, no need.. Karri does yours have Appendix 7? We can start a get Karri a HP ScanJet fund. I bought an old one off Ebay and still working through all my books. It has a feed tray and it does duplex scanning, with OCR software, so I just cut my books up, place a stack of pages in the tray, hit scan. and it does it.. mostly by it self. you get the odd paper jam, grabs a couple of pages at once etc. Slow and steady.
  2. I doubt it was lost, I would imagine that all of the pages were kept and shipped to devs. While it might have been a "more complete" set rather than every dev on the planet. But I would think if one found a physical copy of the documentation in the folder it would have it. Just the person who did the scanning didn't have it. Maybe the stuff we have is the "well I don't need to look at it too much" so it stayed in the folder, while the timing stuff was kept out and "on hand" so it was lost. Anybody got an account on ASSEMbler ?
  3. Or I make my code so middle of the Road, that it doesn't matter. hopefully.
  4. No idea. I'm the johnny-cum-lately, I only have what I can download from here. There is 1 reference to it in the TIFFs we have, but no actual scan of it in the download pack. Nor any fixes in the "errata updates" to gleam info from.
  5. I too was going to float the idea it does it 5 4 4 4 5 4 4 4 as a potential refinement. Re RAS-only while that may be true, that is still an Extra Tick somewhere, its "free" in terms of 4Mhz clocks I guess, but at best it will eat a Tick.
  6. wait I've been an idiot, I'm going to edit above.
  7. I think we can at least bucket maths this to start with. So a 16 colour screen at 160x101 = 80bytes x 102 = 8160 bytes per frame. SCB = 27 bytes Then its byte + width per line For each byte of data Suzy draws she needs to Grab Byte from RAM, grab Sprite Byte, Store Sprite byte back at minimum. so each byte of sprite has a 3 to 6 byte fetch penalty. The question is does she only grab 1 byte at a time, or 2..3...4 regardless From "60Hz: 159 us x 105 lines 16.695 ms (59.90 Hz], 3 lines of Vertical Blank" so 159us = 159,000ns where the 16mhz clock has a full phase of 62.5ns so 2,544 per line, for 105 lines = 267,120 ticks per frame. ~66,780 clocks per frame. If Mikey grabs 8bytes at a go, lets assume 5 4 4 4 4 4 4 4 is the timing. That is 33 ticks per 8 bytes and it needs to do it 1020 times so that eats 33,660 ticks per frame. Refresh will also eat more time and the docs mention that refresh should be done when Mikey does a fetch to make it faster.. not sure if that is the documentation being wishful or how it is actually done... Lets assume that SCB is also 5 4 4 4 4... so that is 109 ticks to read the SCB Optimal case you have a single SCB that holds the entire frame data in it pure literal. So you need to redraw it each frame. So that is 8160 * 3 access, however I would think that each read is going to need to be 5 then 5 4 4 5 4 4clocks as dest, src, dest, dest as the two dest, writing the previous value, then loading the next are most probably on the same page, won't always be but rough cut for now. So each byte needs 13 ticks. 13 * 8160 + 1( for the initial 5 read of Dest ) = 106,081 ticks. This assume Suzy is fast enough to paint "background" mode sprite with 0 dead ticks. I feel this is "not true", but for now. so a 60hz frame - draw DMA - time to draw one sprite to fill the whole background bestish case = 267,120 - 33,660 - 109 - 106,081 = 127,270 left Discuss Seems all of these details ARE documented, I just noted a tiny tidbit in the docs we have that mentions Appendix 7 holds the gory details.
  8. So if Mikey is "asleep" and Suzy has the bus, Suzy will not relinquish the bus in the face of an interrupt. That is a troubling issue to mitigate... At some time Mikey needs to get the bus back in order to grab data to draw the screen, or once this happens does the screen just go black?
  9. If we look at the SNES and it famously dodgy documentation, it still goes into details about how the sprite rendering works, what it calls a pixel on/off etc. It doesn't explain the Master clock timings from memory though Still better than this. I mean they made the A500 and it better documented than this, and its documentation wasn't C64 PRG good(to be fair not much is). The PS2 came with 6 books, of very detailed info about all the custom chips, the bus formats, timings etc. The VU units need strict timings to get optimal, the graphics pipeline show how the triangle rasterizer works in detail. The PSP the "multimedia processor" was a black box, but we still got full details of the rendering pipeline, options and associated costs with it. The PS3 was basically here is a book about the CELL, internal block diagrams etc etc Once you have a cache trying to get strict clock cycles goes out the window, anything without a cache and you can plan clock for clock Yes it better than the other Atari's, better than the Jaguar but it's not up to spec. How you make a blitter chip and not document how it steals cycles is beyond me.. the Amiga documents it quite well. However you have to forgive Enthusi and I, we came from a world were we understand things so well, we can tell if the Shift key, or the Shift Lock key is pressed and they are connected to the exact same lines on the PCB. Its to do with the capacitance and resistance of a real switch vs the carbon pads combined with the deep knowledge of the CIAs Datasheets. We also come from a world where the NMOS 6526 and the HMOS 6526 differ by 1 clock on the interrupt triggering. And on one of my projects I have to detect and handle this case as that 1 clock is enough to make my game splits collapse and the game crash. We come from a world where 1 clock can equal death and we are walking blind through a system that just says "yeah do that it should work","I forgot something, it might come back to me ; it didn't come back to me" it's anxiety inducing..
  10. adding label support is a must. Source code level though is the task of an external debugger. Especially as you have 2 levels of source code you want to debug from There are still some formatting issues withe the "dump" command sadly The CHIS view is to die for Yes those arrows "fold" the code. This telnets into the monitor, so I want to get the monitor VICE spec enough that I can use this tool. I have the Win95 version, not sure how different the SDL version is, but if its anything like the VICESDL, barge pole However the core debugger logic will just be c/c++ so shouldn't be too hard to work with, and I hope to basically copy/paste the VICE telnet type system ( although not the parser as that needs yacc/bison so that can get ditched ) so you will be able to put in the system and avoid the gui GDB is not suitable for debugging hardware, it doesn't have the commands you need for ASM debugging either, for ASM you need a monitor. GDB isn't really suitable for debugging C for that matter either
  11. So it seems the CPU won't go to sleep if you are still using it.. I'm not sure how big the window is for Suzy to take over and for you to stay asleep. But I would think that the set suzy to loop infinity on SCB then send cpu to sleep might just be the magic trick. However the docs imply that is the only way Suzy can work ??? so the sleep is broken don't use it, only you have to use it so a sprite can be drawn???
  12. So I have the code building, and if I end up doing anything serious on this platform, that debugger needs to be fixed.. (or at-least have its command standardized) Is there anything that is really useful to a Lynx that I won't think of that people would like to see?
  13. From the WDC datasheet It's ability to give a 1 clock no slide ISR response would be sooo good on a C64, but as you said not that useful on a Lynx.. As you have timers, getting clock perfect response is possible unlike other machines ( >.> looking at you NES!, the SNES does have WAI but then it also has HDMA so like whateves' ) Make Suzy stretch a transparent sprite over somewhere in a large block, to which you could check a timer to see roughly how many lines you have left and then adjust the VScale on the sprite to compensate? However Suzy runs faster than the CPU so it might eat more?
×
×
  • Create New...