Spaced Cowboy

What it says and how it appears to be ... well ... The is a direct-from-Dell monitor, I'm sure they're honour any warranty, and it works perfectly well right now so I'm not bothered about it - just thought it was worth mentioning.

So mine just turned up today and it does indeed work very well in all resolutions - I think it works best in mono when you set the desktop background to the first non-white pattern rather than the standard checkerboard, or you get a beats-effects in the black/white background, but it syncs seamlessly to all three resolutions, and it's rock-steady, no dot-crawl at all on mine. I do think these are refurbished ones though - the screen had a greasy fingerprint on it, and the enclosing wrap on it was already ripped at the back. No big deal, it works just as well. The packaging was very well done - obviously a custom cardboard box for this monitor, and very well protected for its travels. It's also not as completely dominant on top of the mega-STE as I thought it would be. Perhaps I've just got used to larger monitors in my old age Overall, I'm very pleased with it - combined with a Centurion monitor-switch box it works very well indeed.

The one thing that I'd change would be to give the ST a standard expansion socket that was actually useful on the base machine. I know Atari didn't get much out of the 800XL PBI but they didn't really give it a chance - there was the PBI on the 800XL, it wasn't on any of the other machines, and as soon as the 130XE came along it morphed into the cartridge/ECI port. That "bad experience" doesn't really count IMHO. If they had just made the cartridge port read/write, put enough of the data/address lines on it, and put it into a larger RAM space, it could have made a huge difference. The MIDI ports were really forward-thinking on the ST, but they dropped the ball wrt the cartridge port. Maybe the intern got that one... Alternatively, keeping the CPU socketed, and maybe putting 4 mounting posts strategically around it - then CPU upgrades would be more like the Amiga... Basically the ST was a sealed box, you got what you bought, and despite a plethora of ports, none of them were particularly *useful* for significantly upgrading the machine. That led to a lower life-time IMO. The promise of expandability (even if it's never used) is a powerful draw when you're spending loadsamoney on a new computer.

Thank you for the clarification

There is a slight difference here, the 22" one he's talking about is the P2222H whereas the one that doesn't work is the SE2222H. It's possible the P2222H does work - though we know the SE2222H and SE2422H don't work in all resolutions. Doesn't matter for me - I've bought one now

So this is something of a necro-bump, but FYI the monitor is currently available directly from Dell for $99, with free shipping. I bought one, of course, I just wish the 24/22" ones worked down to 15kHz - 27" is a bit big on top of the MSTE, and the TT sitting next to it (with a Mach64 card) will get jealous...

Well, that's the first pass at a complete "TOS" version (ie: not NVDI 5 or Magic or any other newer stuff) of the VDI written in about a month as a client/server implementation using (in this case unix) sockets to communicate between the application and the display-server. Multiple clients should be able to connect simultaneously, giving a form of multi-tasking. Not that this looks at all impressive (actually, sort of the opposite of impressive ) but the below is a small selection of stuff that was rendered out by the test-app, just to make sure things at least semi-work... What it does show are user-defined fill-patterns and line-styles, vro/vrt_cpyfm, writing modes, flood fill, text alignment, markers, outline text, and in my case the line styles etc. work as you up the width of the line, plus you have arbitrary text rotation It seems a lot faster than my TT as well The next step will be to write a unit-test app that can be scripted to compare output of a "real" TOS (probably actually an emulator) vs the output of the current code for each of the display functions. Then it's on to the AES.... I'm only trying to match this all up to the 'C' level API, so not everything is a perfect fit (example: running vex_motv, you have to provide a C function, and the arguments to the function are the x,y co-ords, the values aren't passed in d0.w and d1.w), but it's pretty damn close, and good enough for my purposes.

This. Still awesome in my head after more decades than I care to recall...

Thank you - advice on the mailing list did actually get me to a working state

Yep, I thought so too Oh it does, I was converting it to RGB 888: int main(int argc, char **argv) { if (argc == 1) { fprintf(stderr, "Usage: pal2h <file.pal>\n"); exit(-1); } FILE *fp = fopen(argv[1], "rb"); if (fp == NULL) { fprintf(stderr, "Cannot open %s for read. Exiting.\n", argv[1]); exit(-2); } uint32_t magic; fread(&magic, 1, 4, fp); if (magic != '10AP') { fprintf(stderr, "%s is not a palette file. Exiting\n", argv[1]); exit(-3); } printf( "#ifndef _palette_header_\n" "#define _palette_header_\n" "/* Palette generated from %s */\n" "typedef struct\n" " {\n" " uint8_t r;\n" " uint8_t g;\n" " uint8_t b;\n" "} RGB;\n\n" "typedef struct\n" " {\n" " RGB rgb;\n" " uint8_t a;\n" "} RGBA;\n\n" "static RGB _palette[256] = {\n", argv[1]); for (int i=0; i<256; i++) { uint16_t rgb[3]; fread(rgb, 6, 1, fp); for (int j=0; j<3; j++) rgb[j] = ntohs(rgb[j]); printf("\t/* %03d, 0x%02x */ {%d,%d,%d},\n", i, i, ((int)rgb[0] * 255) / 1000, ((int)rgb[1] * 255) / 1000, ((int)rgb[2] * 255) / 1000 ); } printf("\t};\n" "#endif /* ! _palette_header_ */\n"); } The values I'm getting out *look* correct in terms of the maths (white is 255,255,255, black is 0,0,0,...) it was just whether the order was correct that I was thinking about. Which it probably is, of course. Just clutching at straws at this point... Cheers

Can anyone point me to a genuine verified-works NVDI-style colour palette file ? Or can anyone confirm that the one in XaAES/.../pal/nvdi.pal is actually correct ? I'm having some real trouble trying to get my parse-the-colour-RSC file code to work. For example, here's two icon files - the top one is what I'm parsing out, the bottom one is the render from the site - and it claims to be using an NVDI palette to do the rendering. I'm getting the correct data from the file, so the structure of the icon is correct, but the colours are all wrong. The thing is that if I look at the hex values of the colour in the "correct" icon, the top left corner of the dark grey box (the first visible pixel) has RGB of 128,128,128. According to my dump of the XaAES nvdi.pal file... static RGB _palette[256] = { /* 000, 0x00 */ {255,255,255}, /* 001, 0x01 */ {0,0,0}, /* 002, 0x02 */ {241,0,0}, /* 003, 0x03 */ {0,230,0}, /* 004, 0x04 */ {0,0,241}, /* 005, 0x05 */ {26,202,186}, /* 006, 0x06 */ {255,255,0}, /* 007, 0x07 */ {230,51,153}, /* 008, 0x08 */ {217,217,217}, /* 009, 0x09 */ {128,128,128}, /* 010, 0x0a */ {128,0,0}, /* 011, 0x0b */ {0,128,0}, /* 012, 0x0c */ {0,0,128}, /* 013, 0x0d */ {0,128,128}, /* 014, 0x0e */ {182,161,57}, /* 015, 0x0f */ {128,0,128}, /* 016, 0x10 */ {0,0,51}, ... ... that is colour index 9 (and there's no others, I checked). I'm getting index 16 (0,0,51), which is why you can see the darker outline around the icon. I looked at the actual binary file loaded in, in planar format, and I don't see a way to get two bits set for that pixel. Here's the dump I've circled the bytes on each plane that form the first pixel that isn't white. Assembling those plane by plane has to either give {0x00, 0x00, 0x00, 0xFF, 0x00, 0x00, 0x00} or (if the highest bit of the plane comes first) {0x00, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x00, 0x00} for the first 8 pixels. Either way, I only see 1 bit being set in each of the 8 pixels, so getting '9' would be ... difficult. The MFDB looks ok... I'm presumably doing *something* wrong, but it's not clear what. If there's a good example of the code to actually parse colour icons out there, I'd appreciate someone pointing me towards it

Nvm, I think I've figured out something that will work for my use-case. I can use one of the reserved flags in the MFDB to indicate there's a colour-table appended to the pixel data.

Hi, I'm a bit confused (even after reading the docs) over how vro_cpyfm (and anything that uses MFDB's actually) works with colours. There doesn't appear to be anywhere in the MFDB to indicate which actual colour a pixel is when the format is the device-dependent one. I can see how the bits identify the "pen", but they don't know that (in MFDB A) pen #1 is 'red' and (in MFDB B) pen #1 is 'green'. Questions: Is the palette just whatever is on the screen at the time, so this doesn't really matter ? What if the screen is 'true-colour' like one of the Falcon modes, or a TT video card ? Is the device-dependent form just 16/24/32-bit packed-data RGB per pixel ? Do the bit operations (eg: S_XOR_D) work on the colour values, or the pen-ids (ie: what's in the video memory). I'm assuming it's the pen-id's, but since I'm asking questions Ta [I really wish otter-correct would stop converting vro_... into bro_...]

Wow, it doesn't seem like last year that I last posted about this, but apparently it was... This post isn't really about any huge development within xtal per se, it's about how I'v been spending that time, and 'spending' the time seems like the correct phrase.. The next goal, back then, was basically to get printf() working - ie: get functions with variable-length argument lists. Printf() may seem like an esoteric target this early on, but it's a surprisingly useful debugging tool, and being your typical lazy programmer, I like to make my life as easy as possible However, one of the things about printf is that it takes variable types of argument as well as variable arguments themselves. My plan for this is for the compiler to emit (at the call-site) an encoding of byte-lengths for each argument, so the assembler can figure out what to put where in the register-assignment. It'll make the AST a bit more difficult, but it ought to make the assembler's job a lot easier. While I was thinking about that, it occurred to me that now would be a good time to get the f32 (float) type into the language - we have all the integer types I'm expecting to support (signed and unsigned 8,16 and 32-bit types), structs are on the horizon, and the last outstanding primitive type is the float, which would make my yet-to-be-written printf() even more generic... "Ok, let's add floats", I thought. That was last year. Floats have been metaphorically kicking my behind since then. To the point where I stopped, and wrote a small debugging tool to help me out. It's incredibly useful to be able to page back and forwards through time to see what's happening in memory (and more importantly, why). The largest obstacle though, as will become clear, was my own understanding of floating point formatting... I originally started out using Woz's floating point routines [PDF link], and it all started reasonably well, I wrote myself a small command line app "wozf" that let me type in a float and get the correct representation (or so I thought) and everything was proceeding pretty well until it got to the test-suite stage. I couldn't get it to subtract 9 from 2, it always gave me -1 not -7, and I couldn't for the life of me see why. I reached out for help on the 6502 forum where there was a suggestion that the bias offset was different for negative values compared to positive ones. That made sense in isolation, but it didn't seem to work for other examples... I was fairly sure I was doing something wrong, and that the code was fine - I'd compared my code to his oh, about a thousand times - and I couldn't see any typos. I checked the simulator (that was fine), I checked my assembly output (that was fine). So I gave up - and this was when I started writing the debugging aide above. I wanted to step through things and see them happening, and I wanted to be able to cross-jump between the source-code and the instruction stream to jump around the code easily. A couple of weeks passed while I got this up and running. And then ... I still couldn't see anything wrong [sigh] I decided to look around for other FP engines - I looked into MS basic (but didn't like the 40-bit format, I wanted it to fit into the same space as a u32), I looked at BBC basic, same problem (5 byte floats). Eventually I found an older implementation: the 6502 Software Gourmet Guide and Cookbook [Internet archive link]. This was a 4-byte FP system from 1979 (!) which was actually pretty similar to Woz-format, maybe slightly simpler, but it also had the advantage of "good documentation", and it's written to be far and away more straightforward to follow - Woz was a fiend for compressing his code into as small a space as possible, and it can make it hard to follow the jsr to this that jsr'd to that, which jsr'd back into this etc. This is fine when you know the code (especially if you've written it). When you're trying to grok it, it's ... not so fine. I couldn't find a source with the book-code already in text format (the PDF is just images), but I figured that typing it in might give me a better idea of how it worked anyway, so that's what I did. I found a few typos in the code in the book, but it all went fairly smoothly... Until I tested 2-9, and got -1. Ok, two completely separate implementations of floating point, both giving the same "wrong" result, means it's definitely a PEBCAK problem. I used my new debugging aide to step through, writing down notes as I went, and finally the penny dropped. Stepping through the code made it clear, the logic works well and we got to the penultimate step with an answer of +7 in the accumulator when subtracting 9 from 2. It then complements that and you end up with 00:00:90:03 I was interpreting the high byte of the mantissa as $90 = 10010000 smmmmmmm 0x80 = 1 -> negative 0x40 = 0 -> 0 x 0.5 0x20 = 0 -> 0 x 0.25 0x10 = 1 -> 1 x 0.125 where the exponent = 2^3 = 8 => (-1) * (8) * (0.125) => an answer of -1 But that’s not the case - the mantissa should be regarded as valid for the number of bits specified in the exponent, and if it’s -ve then its a left-aligned 2’s complement number, so 0x90 is more recognizably specified (if it were a 32-bit int) as 0xfffffff9 or -7 And 2-9 is indeed -7, so the logic works just fine. I think I was being thrown off by the large number of zero-bits in a negative number, I normally expect to see an exuberance of 1-bits, and I hadn't twigged about the mantissa valid-bits being governed by the exponent. I also think the far-more-logically-straightforward treatment of floats in the book made it a lot clearer what was going on, even though Woz's code produces exactly the same sort of result. Anyway, right now I have addition, subtraction, multiplication and division working to my satisfaction, and also input (ascii->float) and output (float->ascii) routines, although the float->ascii could probably do with a little polish, you always get scientific notation as output, and it doesn't trim trailing zeros... I also rewrote my little command line utility as a class, which I'll integrate into the assembler so I'll be able to have things like: m_pi: .float 3.141592 .. in the assembly. It turned out to be really useful on the command line: @elysium % float65 0x1d906402 Float: 3.142592 @elysium % float65 3.142592 Hex : 1d.90.64:02 This has been a pretty long post, so as a little bit of eye-candy, this is the result of calling 'FP_ftos' on the floating point representation of 2 If you look closely at the buffer starting at 0x40 (it was just easier to have all the changing registers/values on the same page, I wouldn't really put stuff there), you can see the sequence: 2B 30 2E 32 30 30 30 30 30 30 45 2B 30 31 00 or +0.2000000E+01 (with a trailing \0) This gives me the basics of a working floating point library (most of the other typical FP functions can be expressed in terms of the 4 basic ones) and a way to get the data into and out of the floating point realm. Now I have to create the 'float' types in xtal, and get them worked through the compiler and assembler, as well as the various conversions to and from float to ints of various lengths But since this has been, as mentioned at the top, metaphorically kicking my behind for a month or so, getting to this point feels like progress, and I got a reasonably useful debugging tool out of it too, so today is a good day, well better than most of the past month or so, anyway

Cool - that makes life easier. These routines should never involve any I/O, so I'm good to use them, I reckon. I've already co-opted $1C..$1F as general-purpose pointer vectors but those are currently unused at all - I'll have to look around for other possibilities