Ittiara, a 65C02 handheld

[DerTrueForce]

That LineEnding label is defined in IttiaraROM.asm(the top source file).
I made that CMP into "CMP #LineEnding|$80", doing pretty much what you were thinking of.
But changing the definition of LineEnding like that might possibly solve the other issues I've been having. I'll try it.

[DerTrueForce]

I defined a new label for the line ending that EWOZ uses(It's the same as LineEnding OR'd with $80), and then changed EWOZ to use that instead of the old line ending label. EWOZ now seems to work correctly.

I also put in a jump table at the end of the ROM image (SB-Assembler makes this needlessly awkward), as I found that things have started moving around and not working properly.
While I was doing that, I found a problem in one of the SPI routines, where it was trashing A. Part of the point of that routine is to preserve A, so I fixed that.

That made the SPI loader work(or rather, the version that I punched into EWOZ), after I fixed a stupid off-by-one that I committed on paper.

[GaBuZoMeu]

Wow Sounds good to me

Having a running and stable monitor you can explore every hardware (and software) step by step and surely a lot easier than before. Sure you will add some tools loosely to the WozMon to make further progress more easily. Don't forget to backup your actual state from time to time - just in case

Good luck!


Arne

[ttlworks]

Nice progress so far.

I'm happy, that fixing those software problems wasn't too difficult.
Looking forward to see, how the project continues.

[DerTrueForce]

I've got a local Git repo on the source files of the ROM(but not the build artifacts), and I will back it up in some way, if only by copying it off to an external hard disk every so often.

The monitor was really helpful in making this work, but I'll still build the Bus Bug. I've already ordered the parts I'll need, so I may as well finish what I started. (Actually, I might not have the sockets... I'll see.)

I think the next step will be to get a set of working, general SPI read/write routines going. I'm not entirely happy with the way I did it the first time around, but I might not be able to do it much differently. They need to take in a 16-bit source address, a 16-bit destination address, and an 8-bit length. I've been using hard-coded ZP addresses to pass those, and it feels dodgy, but I don't really see any better way to do it. I could use the index registers to store ZP indices to the addresses, but that feels similarly awkward.
I wouldn't have that problem if I were using the '816, of course. That'll probably be the next step for the hardware(possibly via an adaptor board, unless I do a separate design based on it. But that's for the future.

[GaBuZoMeu]

Well, the 6502 isn't a processor to submit "hundreds" of parameters within its registers. It is common to have at least one pointer in ZP to a "scratchpad" area where you can place your parameters. And if you wish to have it reentrant - well then you have to manage the pointer . I would suggest to start simple and get it running. Doing "artwork" or trying to fulfill any possible condition may come later

Remember: have fun!


Regards,
Arne

[DerTrueForce]

I've now got working 25AA512 support in the Ittiara ROM. It only consists of a few routines to allow reading and writing; there's no integration with anything as yet.
I ended up having these routines transfer 256 bytes at a time, with a set "staging area" where the data comes from/goes to. I basically assumed that there's always 256 bytes of data being moved, that the EEPROM start address is always on a 256-byte boundary, and that the 6502-side source/destination is always the same, and coded that into the new routines.

There was one thing that wierded me out in the read routine. Both the read and write routine take in the slave mask in A, and the EEPROM page in X. I preserve the registers through both routines, so I push A first, then X. When I need X, it hasn't been changed since the routine was entered, but for some reason, if I put a TXA in there, it doesn't work at all, but it works just fine if I do PLA PHA.
I assume it's some kind of timing issue, since the routine I adapted it from had a LDA #$00 there. I don't think it's a huge problem, unless it's an indicator that something else is wrong. It's only one extra byte, so I'm not too concerned, given that it works.

[Dr Jefyll]

Quote:

I'm not too concerned, given that it works.

I suggest you follow up on what is probably a valuable clue.

PLA, PHA (which works) is 7 cycles and 2 bytes, so what happens if you use BRA $00, NOP, TXA? This preserves the timing.

Another experiment: replace PLA, PHA with TXA, NOP. This preserves the number of bytes. (Yes, this might matter.)

Like you, I have a feeling this might be an indicator that something else is wrong.

-- Jeff

[DerTrueForce]

I had considered dropping a NOP on it.
I copied the original routine into RAM(manually, by reading the list file. Probably should have tried MEMCPY...) and that worked. No surprises there.
One with NOP TXA works, and so does the BRA 00 NOP TXA. Strangely, one with only TXA also works.
The big variable I see here is that I'm now running from RAM. I'll put the test pieces into ROM, and see what works and what doesn't.

[DerTrueForce]

I'm noticing that the 65SPI is getting quite hot. Almost too hot to touch. I've been told they usually run hot, but this seems a bit extreme.
Anyway, now all of them seem to work. Including the TXA-only one. Perhaps I goofed up?

[DerTrueForce]

I managed to get my Parallax Propeller to behave as an SPI-attached SID. I just send it the register number and then the data to go in that address.
It can probably be improved by including a counter, and allowing it to write up to three addresses in one hit. The SPI object I'm using only pulls in a 32-bit value at most, and I need a byte(or near enough) for the start address, which is why only three bytes of data.
The SID also has only 28 registers, which fits in 5 bits, so I could potentially make use of the other three bits to control other software in the propeller(I'm not using most of its resources at the moment). I think some 3.3V IO could come in handy, although I could probably put nearly anything in it.

[DerTrueForce]

It occurs to me that one of my goals has shifted since I last posted them.
I've decided that I want much better graphics capability than I have now.
Black and white 128x64 is serviceable, but what's really getting me now is that I don't have a lot of room for text on the screen. 21x8 characters is surprisingly restricting.
I plan to shoot for a resolution of around 320x200, with 256 mappable colours(essentially VGA mode 13), tiles/sprites, scrolling, and a text generator(obviously). I also want the display data to be visible to the main processor.
Trouble is, VGA 13 needs 64K on its own, and I'll need more for the other features.
I could go a couple of ways with this. I could use a Gameduino 3, which would exceed my desires graphics-wise, and comes with a nice big display and a couple of other things that I don't feel any particular need for, but could be really nice to have. However, it would not make the VRAM available to the CPU, as far as I know.
The other option is to roll my own, which I can see would be a lot of work. I'd probably need an FPGA to implement all of what I want to do, and I'd need more memory than the 65c02 can address, so I'd need to go to a 65816. That memory will likely not be cheap, either, given that large SRAMs seem to be quite expensive. And I think I'd also want to go to 3.3V if I did that, because I don't really want to have to put a level converter on the main bus.
I'm leaning towards the Gameduino.

I might switch to a 3.3V, 65816 design anyway, come to think of it. 5V devices seem to be becoming the exception, which is both irritating and annoying, so I might as well move with the times and shift to 3.3v logic. It doesn't conflict with my speed goal, and it's easier to shift from low voltage to high, as well.
The 816 is also looking rather attractive at this point, with it's larger address space and registers. That said, SRAM isn't cheap, and DRAM is more complicated to use than SRAM. Async DRAM doesn't seem to be common either; SDRAM (SDR and DDR) is mostly what I've seen, which seems complicated to work with, and usually isn't 8-bit wide. I'd like to keep chip count down if possible, so I'd want to try and use the one IC for the job.
I am aware of Garth's 4MB fast SRAM module, and I might yet use one, but the devices used are 5v-only according to the manufacturer, and the price makes me want to be very certain that I want it before I ask about them, or a possible 3.3v version.

[GARTHWILSON]

DerTrueForce wrote:

That memory will likely not be cheap, either, given that large SRAMs seem to be quite expensive. And I think I'd also want to go to 3.3V if I did that, because I don't really want to have to put a level converter on the main bus.

It looks like asynchronous 2Mx8 SRAMs that operate at 3.3V and come in non-BGA SMT packages cost about $15-20 in singles at Digi-Key. These are about 1/4 of the speed of mine; but at 3.3V, you won't be going as fast anyway.

512Kx8 cost about a quarter as much in singles. (I do better since I buy 100 at a time.)

If there were a demand, I could make a 16Mx8 3.3V SRAM module. I held it down to 4Mx8 using eight 512Kx8 SRAMs because they're the densest SRAM chips you can get in 5V.

[DerTrueForce]

I'm seeing much the same on Mouser.
Looking at mean price, it's actually a bit better value to go for a single chip, although there doesn't seem to be a great deal of point in getting 2MB. I can't think of what I'd do with that much memory, if I'm honest. Not at the assembly level.
I had considered DRAM, but it looks like the ones Mouser stocks are either too complicated, in a BGA, and/or 1-2V stuff. I think I should stop looking.

I've probably let myself been influenced too much by the 8-Bit Guy's dream spec(Link), but now I think that since he's not thinking of a handheld, and that Ittiara is meant to be my spec machine, I should probably not shoot for that.
The huge RAM probably needs to go. I don't particularly feel like throwing $25+ at memory(I didn't pay that much for the 'C02!). Mouser has 3V3 512Kx8 SRAMs for just under $5, so I think I'll get one of those instead.
I think I should still move to the '816, just so I don't restrict myself to 8-bit-only.
I do still want more display real estate, and while I might not use the graphics capability, I still want it there. The Gameduino still looks good for that, but it's not very text-oriented, which is mainly what I use at the moment. The C++ driver they provide doesn't look particularly nice to translate, but I think it'll be easier than building my own GPU.

[Dr Jefyll]

DerTrueForce wrote:

I can't think of what I'd do with that much memory, if I'm honest.

For code, yeah -- there's a limit to how many routines you're going to write or include.

Data is different, though. You don't have to write data... but you might want to collect (and/or manipulate) a whole lot of it! In that sense the need for data storage is open ended in a way that the need for code storage isn't.

Quote:

Mouser has 3V3 512Kx8 SRAMs for just under $5, so I think I'll get one of those instead.

If it's the ones in the J-lead package you're thinking of, remember it's quite easy to uncurl the J's of one chip and piggyback it on top of another chip that's mounted in the normal fashion. For under $10 you can put a megabyte in less than one square inch.

(I used a little daughterboard to do this, and I staggered the leads to match the 0.1" grid. But you can dispense with both of those tactics if you go with a PCB or use a protoboard with 0.050" grid. The result will be even more compact than what you see here, and tidier -- just one flying lead to connect to a CS on the upper chip.)

-- Jeff