Jump to content
IGNORED

Which CPU does it actually have?


oziphantom

Recommended Posts

So some things says 65CS02, then the Lynx II got an upgrade to the 65C02.. WDC don't list a SC but an 65C02S.. Do we know if its WDC spec, or Rockwell spec?

 

wikipedia has this

The 65SC02 is a variant of the WDC 65C02 without bit instructions.[2] The WDC 65C02 is the base for the HuC6280 by NEC used in their video game console TG-16 (PC-Engine)[3]

However when it says bit instructions does it mean the BIT instruction as well or does it just mean the Rockwell 65C02 BBR1-7 BBS1-7 RMB1-7 SMB1-7 instructions,

 

I found a note on a doc by Oxyron that the '65SC02, doesn't have the single-bit instructions BBR/BBS/RMB/SMB.' which means it probably still has the BIT instruction, but not the Rockwell extra instructions.

However WDC also added WAI and STP to some of its variants, does the Lynx CPU have these instructions as well?

 

I was able to find a Datasheet for a G65CS02 but it is from 2000.

 

the 65XX family is such a mess XD

Link to comment
Share on other sites

So some things says 65CS02, then the Lynx II got an upgrade to the 65C02.. WDC don't list a SC but an 65C02S.. Do we know if its WDC spec, or Rockwell spec?

 

wikipedia has this

However when it says bit instructions does it mean the BIT instruction as well or does it just mean the Rockwell 65C02 BBR1-7 BBS1-7 RMB1-7 SMB1-7 instructions,

 

I found a note on a doc by Oxyron that the '65SC02, doesn't have the single-bit instructions BBR/BBS/RMB/SMB.' which means it probably still has the BIT instruction, but not the Rockwell extra instructions.

However WDC also added WAI and STP to some of its variants, does the Lynx CPU have these instructions as well?

 

I was able to find a Datasheet for a G65CS02 but it is from 2000.

 

the 65XX family is such a mess XD

 

The Lynx has the BIT instruction but not BBR/BBS/RMB/SMB/WAI/STP.

Link to comment
Share on other sites

If I dare throw some speculation into the conversation:

 

As usually described, the instruction set of the Lynx 1 matches that of the Synertek 65C02. It's just a core embedded into Mikey though, rather than an actual discrete part, so one can pretty easily imagine that's where the S comes from — to denote which of the three 65C02s it is like without actually naming a manufacturer.

 

That in the Lynx 2 is like the Rockwell 65C02, which supersets the Synertek.

 

Had there been a Lynx 3, perhaps it would have moved on to modeling the WDC, which supersets the Rockwell?

 

(EDIT: corrected for a poor memory; I had WDC and Rockwell the wrong way around in terms of instruction set size)

Edited by ThomH
Link to comment
Share on other sites

So its R spec not W spec... damn the WAI is the killer instruction!

 

It's not all that useful on a Lynx, as there's really not a lot you can do by racing the beam. The only thing happening in real time is output of a frame buffer — there are no hardware sprites, there's no tile map, etc — so palette changes are probably the full extent of potential effects.

 

E.g. if you pause Roadblasters and inspect RAM you'll see that the curved road is just something that has been drawn to a bitmap. Compare and contrast with other 8-bit consoles, and some of the computers, where you'd achieve that by twiddling the scroll offset as the frame runs.

Link to comment
Share on other sites

Oh, it's WAI from a power-saving point of view?

 

Given that the intended power-saving hardware doesn't work on a Lynx, it might also be interesting one day to do a search for the optimal way to waste time? E.g. does Suzy running what amount to a no-op loop consume less power than the CPU? What about constantly trying to interact with the cartridge or with the audio subsystem in order to generate CPU waits while you loop waiting for end of frame? Etc.

Link to comment
Share on other sites

Oh, it's WAI from a power-saving point of view?

 

Given that the intended power-saving hardware doesn't work on a Lynx, it might also be interesting one day to do a search for the optimal way to waste time? E.g. does Suzy running what amount to a no-op loop consume less power than the CPU? What about constantly trying to interact with the cartridge or with the audio subsystem in order to generate CPU waits while you loop waiting for end of frame? Etc.

From the WDC datasheet

WAit-for-Interrupt (WAI) and SToP (STP) instructions reduce power consumption, decrease interrupt latency and provide synchronization with external events

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?

Link to comment
Share on other sites

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?

 

I was thinking more like ask Suzy to draw something that isn't even on screen, and link that SCB back to itself. So Suzy will enter an infinite cycle of reading the SCB, reading the source data, not drawing anything, and repeating. Until an interrupt comes, causing Suzy to stop and passing the bus back to Mikey.

 

There's no reason whatsoever to believe it would save more power than `.here BRA .here`, or that it necessarily wouldn't. So it'd just be interesting to know. It doesn't actually decrease memory usage, so polling one of the hardware registers that temporarily blocks the CPU (i.e. cartridge read or the audio shifters) is probably a better guess.

 

Both much worse ideas than if CPU sleep actually worked properly, though I had the opposite impression to Karri: I thought it woke up much too often, rather than potentially never waking up. If it were the former, that'd presumably still be the way to go.

Link to comment
Share on other sites

BIG NOTE: Sleep is broken in Mikey. The CPU will NOT remain asleep unless Suzy is using the bus. There is no point in putting the CPU to sleep unless you expect Suzy to take the bus. We will figure out how to save power some other way.

I will still keep the following paragraphs pertaining to sleep in this spec.

The CPU can put itself to sleep by writing to the CPU disable address. The CPU wants to sleep for two reasons. The first is that it is done with all of its work and we would like to conserve battery power. In this case, the CPU would pre-arrange for an interrupt to wake it up at the next time that work needs to be done (probably vertical restart). When awaken by an interrupt, normal interrupt vectoring takes place. Note that if no interrupt occurs, the CPU sleeps forever. An interrupt will wake you up even if they are disabled inside the CPU. The second reason to sleep is that Suzy has been requested (by the CPU) to do work. In that case, it is up to Suzy to awaken the CPU when it is done. When awaken by Suzy, processing continues from where it left off. The CPU cannot fall asleep unless it puts on its pajamas. This is accomplished by disabling all interrupts (register in Mikey) that you do not want to wake you up, then clearing them (in case they came in while you were disabling them), and then writing to the Suzy Wakeup Acknowledge address IF you were woken up by Suzy (or if this is the first time you are going to steep). The purpose of the Suzy Wakeup Acknowledge address is to prevent missing the wakeup request from Suzy should it occur exactly at the same time as an interrupt.

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

 

When you are ready to start the sprite engine, the following steps are required:

  • Write the base address of the video build buffer into VlDBASE.
  • Write the address of the start of the first RAM sprite control block into SCBNEXT.
  • Write a '01' (or '05') to SPRGO, turning on the sprite engine.
  • Write a '00' to SDONEACK, allowing Mikey to respond to sleep commands.
  • Put the CPU to sleep, allowing Suzy to actually get the bus.

??? so the sleep is broken don't use it, only you have to use it so a sprite can be drawn???

Link to comment
Share on other sites

Why should 16bit Suzy consume less power than 8bit cpu?

 

Why shouldn't they? I suggested it was a potential area for exploration.

 

I'm going to avoid getting into what's x bit and what's y bit completely.

 

 

Also how long are CPU halts on cart read at max?

Or: how slow can a cart read get?

 

Per the documentation, up to 15 ticks for a cartridge read, up to 20 for an audio shifter read.

 

If you're asking me to guess — even though the main thing I'm saying is that it would potentially be interesting to get into a position where we didn't have to guess — I think that reading the DPRAM would probably be more power efficient as that's just Mikey talking to Mikey. Not Mikey talking to Suzy talking to the cartridge ROM.

 

You've just to figure out which of the audio registers reads from Mikey's dual-ported RAM. I'm an audio dunce, so don't trust me, but I guess that volume is the main one?

 

It's implied that the pause is caused because the four audio channels are available to the CPU only in a round-robin fashion, so you might even do better with a loop that deliberately polls them in reverse order, assuming you can figure out which order is reverse!

 

It is a frustratingly under-documented platform.

 

 

??? so the sleep is broken don't use it, only you have to use it so a sprite can be drawn???

 

My understanding was that sleep works for as long as Suzy wants the bus, but doesn't work for power saving. Or doesn't work properly, at least.

Edited by ThomH
Link to comment
Share on other sites

 

It is a frustratingly under-documented platform.

 

 

So, you haven't checked out the Jaguar.

I find the Lynx docu very much complete. Exact timing information is missing, but one should not rely on this anyway.

Remember that the first development was done on the Howard-board which had a dozen of TTL chips and GALs. I doubt that it had the same timing.

I guess, if you look at modern consoles, there are probably more things undocumented (let alone the GPUs).

Link to comment
Share on other sites

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..

  • Like 1
Link to comment
Share on other sites

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???

Yes. And if you make an endless sprite-chain Mikey never wakes up again. I tried it once with a Tut-Anch image, but the code does not work any more. :(

Link to comment
Share on other sites

Correction: The Lynx model 1 dpoes not have BBR BBS RMB ... but Lynx Model 2 has it.

 

Your sure about this? Did you test it?

And if so, which Lynx II, both versions or only the stereo version?

Edited by 42bs
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...