So i have toyed around with asm on the Ti84+, as i wanted to create a shell. Then i decided the CE would be a much better target. So, i basicly have a bunch of questions

1) How is the screen buffer data structured and where is it located? With the 88+ it is easy because one bit is one pixel.

2) Are there major differences with the VAT? Is it still structured the same, and is there still a useless byte avalable, as to allow folder systems to be implemented as doors does on the 84+? Further more, how do i get a pointer to the vat?

3) Lastly, what assembler should i use?

Thank you for your help. I still dont have a CE,, and i wont be able to get one for a long time, but i hope to get one eventually

1. The screen is completely memory-mapped at vRAM, in which there are two bytes per pixel. You can use the same location in 8bpp mode using some complicated-ish stuff described here: https://www.cemetech.net/forum/viewtopic.php?p=240544#240544
2. I don't even know what the VAT is.
3. SPASM is amazing: http://wabbit.codeplex.com/

2) Yes, the VAT is structured the same, but the page ROM address has been replaced to allow for the whole 24 bit address. To get a pointer to the VAT in HL, do "ld hl,(progptr)". Good luck!

In order to help clarify (1), yes, the screen is indeed memory mapped, but it doesn't just have to use vram to display. The GRAM pointer can pointing anywhere in memory, useful for page flipping and double buffering.

Well, I didn't really look at the screen part yet, after all this is just something I am looking forward to in the future. But, can Brass be used to compile for the ez80?

Also, how hard would it be to mostly keep one code base for both a SE and a CE? I remember geekboy said something about the reasons E:Tor has 8pxl movement is to make it easier to port to the ez80 or something

Edit: also, I don't think I have found a complete instruction set for the ez80. I know it's mostly undocumented, but still..
Like or example, what does a ".SYS" mean after an instruction?

Nope. spasm-ng is the way to go. You could also use SourceCoder, which is powered by spasm-ng.


Certainly not impossible. Obviously you'd need entirely different graphics-related code and data. But probably the trickier part would be properly handling all the small differences dispersed throughout related to word size differences.


It's completely documented: http://www.zilog.com/docs/um0077.pdf.

Runer I was looking for a quick instruction set like the one found on clrhome, not a 200 page long document. Also, can you provide some more info on the structure of the palette? I mean, like rgb24, one byte is red, one is green ect. But how is the palette structured? From a quick glance at the pellete, it seems the structure is something like bbrrrggg, but thats just an estimate. And what about vRam itself? If two bytes = one pixel, does that mean that i have to skip every other byte when writing to vRam in 8 bit mode?

I'm not exactly sure what you consider about that table to be quick, but there is no eZ80 version of it. However, there is an opcode map (not interactive, of course) at the end of the document if that's what you're looking for. Or if you're trying to look up a particular instruction, I'd suggest simply locating it in the bookmarks list provided by your pdf reader of choice.


In addition to the eZ80 manual, you should probably also grab the the LCD controller and have the relevant WikiTI page bookmarked. Both mention that the palette is composed of 256 16-bit entries, where each entry is a color in the 1:5:5:5 format. This format has 1 "intensity" bit that is shared as the least significant bit of all colors, followed by 5 blue (or red) bits, followed by 5 green bits, followed by 5 red (or blue) bits. The parenthesized colors are used if you reset the BGR color order bit, but it's set by default.


Nope. The LCD controller always expects the data to be tightly packed, so the 8bpp palettized mode means one pixel per byte. There are also 4bpp, 2bpp and 1bpp palettized modes, which mean 2, 4, and 8 pixels per byte, respectively.

hmm... do you think in 8bpp mode i can feasibly use VRam+(width*height) as a ram buffer?
Speaking of which, what are the other free ram areas?

Ohh, and btw, has someone made a program to read png files and output the hex acording to the above linked palette?

You certainly can, and that's a fairly common method. You can specify the buffer pointer by writing it to the LCDUPBASE register of the LCD controller, which is mapped to the word of RAM at mpLcdBase.


Search for "safeRAM" in the include file.


This question, I don't have an answer to. I feel like Iambian might have, but I don't think that was ever published. Or if you don't need an offline program, SourceCoder can do it, though you'll need to reformat the data to be able to include it in an assembly program.

Also look at the saferam stuff here : http://wikiti.brandonw.net/index.php?title=Category:84PCE:RAM:By_Address


Mateo's PicConvert CE feels appropriate here...

Well as i am not on a pc i cant check out iambians tool, but i will copy paste the safe ram for my own reference. (this is prety much a "c4ooo's CE questions" thread by now )

SafeRAM Areas:
D031F6h: pixelShadow - 8400 bytes
D052C6h: pixelShadow2 - 8400 bytes
D07396h: cmdPixelShadow - 8400 bytes
D09466h: plotSScreen - 21945 bytes
D0EA1Fh: saveSScreen - 21945 bytes
Note that the above is contiguous, which provides a total linear free space of 69090 bytes of RAM.
pixelShadow2 is the most stable; and is a viable option for testing TSRs and hooks.
More SafeRAM Areas:
D006C0h: textShadow - 260 bytes
D0232Dh: cmdShadow - 260 bytes
Also, if you do not wish to use the LCD cursor:
E30800h: CursorImage - 1020 bytes

Thank you every one for your help Hopefully i can soon start using my newfound knowledge

Looking back, i hope this did not come of as rude, it was not meant to be >.<

I arrived a CE, hopefully it will arive in the mail soon

Even in 8bpp, the vRam is a whooping 75kB! if i have game/program with a splash screen, should i store a scaled down version of it and scale it up at runtime as to not hit the excecution limit with giant 75kB splash screens? Speaking of which, what is the execution limit?

You have a few options:

1. You can store a smaller image as you suggested and scale up at run-time, eg. store the image as 160x120 and scale up x2. This means the source image data would only use 1/4 of the memory.
2. You can store the image in 4bpp (max 16 colours) and convert to 8pp at run-time. In this case, the source image data would use 1/2 of the memory.
3. Both of the above, which would result in the source image using only 1/8 of the memory.

If you need help with a routine I'm happy to assist (the colour version of Alien Breed I'm working on uses one of the above methods for the splash screen - I can't remember which, I'll have to check when I get home). Of course, I always recommend trying to write your own routine first to see what you can come up with, it's a good way to learn But like I said, happy to help if you get stuck.

Alright, i am having a problem.
This is my code right now:

Code:

This code produces a black screen with a few white pixels in the corner, and no image.
When i comment out the "call clearScreen", then the image is drawn correctly, and the screen is black, but there are some random grey pixels on the left hand side.

Code:


Your problem is that hl contains the address of the sprite. When you call clearScreen, hl is overwritten. Simple solution: Clear the screen, then load the address of the sprite:


Code:


Also, a word of advice; I usually write code with one tab on the left, and one between the opcode and arguments. It just looks cleaner

Haha! Didn't notice that

Any idea why my code crashes if i replace the clearScreen code with the following code?

Code:


Surly

Code:

is better then

Code:

?

First off, it should be ld de,vram+1, which loads the *address*, not the data at that address. And no, it is smaller to do the second option: (although not nearly as fast; but I generally optimize for size)

First assembly:

Code:

Second assembly:

Code:

c4000, here's my version of "ClrHome" in eZ80 :


Code:

Didn't you forget the "ld (hl),0"?

I wrote a routine to display the same 16*16 image on the first row 20 times. Any optimization (size or speed) tips? 'Drawsprite' takes hl as the sprite pointer and de as the location.

Code:

You want to display 20 same sprites (16x16) on top row ?

Well...Here's my suggestion (in 8bpp) :

Code:


As the total width of the 20 sprites side by side = 320
I chose to display 1st line of each sprite along the screen width, then 2nd line ,...3rd one, an so on

Push/Pop are slow, that's the reason why I use sbc hl,bc and add hl,bc instead