Jump to content

paulscottrobson

Members
  • Content Count

    116
  • Joined

  • Last visited

  • Days Won

    1

paulscottrobson last won the day on November 28 2020

paulscottrobson had the most liked content!

Community Reputation

46 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I use a stock palette which is loaded into 240-255 - the first 8 are the digital RGB and the other 8 I just thought might be useful, Sprites are all set up with the offset %1111 to make them use it, then the sprite converter does a best distance calculation to pick one. Seems to work reasonably well. Can use alternate palettes if you have a different environment say everything is metallic grey. I'm not sure that 256 colour palettes for pixels are really that useable, there isn't that much VRAM available. Maybe for a main sprite.
  2. Not sure it's possible to replicate NTSC colour electronically. Possibly spraying a layer of mud on the screen would work. I always though the colours were shows because they were the least awful looking on a NTSC Analogue TV.
  3. Never was a big game player, though I remember removing the anti copying from the BBC Micro version of "Alien 8". It worked by exclusive ORing with a free run timer, so when you put code in the numbers were out, so if you changed it you had to let the counter go all the way round to correct the value, which meant it ran about 60,000 times slower than usual - rather than decrypting in about 2 seconds it took over 24 hours. Worked though
  4. Elite would probably have to be 160 x 120 x 256 resolution to get the frame rate anything like. You have two basic problems 16 bit maths vs 8 bit maths and the way you access the screen. Michael Steil and I both have written Bresenham type algorithms independently for 320x200x256 mode and they do about 2 a frame, or 120 a second. Don't know if this is using 8 bit arithmetic or 16 bit to calculate its rotations but it makes a heck of a difference.
  5. I think the plan is to have a ZXNext type kickstarter, but they can't do that until there is a solid working prototype. Watch this space basically. I'm sure when it does happen, 8BG & Peris video channels and the forum and facebook will make it obvious
  6. I know what you mean. I've been contemplating this for a while myself, and I've concluded it's not actually possible - unless you don't have very much moving. Pacman is probably about as far as you can go - half a dozen active screen objects that move about.
  7. Good idea Mind you, I suppose that's getting close to a compiler again.
  8. Oh, that's pretty much what it does. It just detokenises the tokenised code There are two main handicaps. The first which we are stuck with is 32 bit (or 16 bit if you like) multiply and divide. Float or Int, you have the same problem, it still has to be done. Short of having a hardware multiplier (can live without divide mostly) there isn't really an answer to it. The second is accessing variables and other identifiers fast enough. Mine uses several techniques : A-Z are done seperately as on the BBC Micro. Rather than one linked list there's 8 linked liists accessed via hashes. Checks on hashes are done before checks on the full name, and the name itself is tokenised so it doesn't have to be parsed, it's easy to find the type and the end and so on. Whether doing what some of the semicompiling BASICs do (have you ever looked at DAI Basic ?) in the way of storing identifier addresses inline in the code is worth the extra effort is debatable. You might get another 20-30% with such techniques (I wrote a language called RPL which is rather like a cross between BASIC and FORTH and does most of these things) its debatable whether it matters. The extra step to get the speed required isn't there. It's not even there if you compile to pseudocode. Compiling to assembler has the usual problems you have with the 6502 e.g. 16 bit operations are very verbose. I don't think having RPN already available gains you an awful lot in processor time. I always reckoned you could produce a fairly easy to use programming system if you had a fast CPU, or lots of directly available memory. At the moment you are stuck between two stools. If you generate 6502 code it's too long. If you generate p-code it's too slow. I did have an experimental compiler that did both, and could be switched on request following the 90/10 rule, but the language was quite limited and to expand that into a full programming language is quite a task. Even normally efficient things like FORTH do not have the speed they really need for this machine. The other problem is if you store it in dual format you effectively halve the RAM, and there isn't that much of it unless you stick it in banked memory.
  9. It's worthwhile, but not enough to get out of writing assembler. If it was 4-5 times faster you could write 80s style arcade games pretty much entirely in BASIC.
  10. Some and some. Infix to Postfix would work, except that if you are (in this example) doing multiplies the 6502 time spent doing that tends to dwarf the time climbing the parse tree (which actually is fairly minimal). My Basic does most of these and it's probably only 40-50% quicker than Microsoft BASIC, much of which is down to 32 bit math being 32 bit math. The only thing that isn't tokenised is text in quoted strings, and that's stored with a precalculated length.
  11. Basic Trigs, Logs, Exponents and most of those similar functions, and powers, are Taylor Series (not sure about Square Root) which approximate to those values. The BASIC has very little other than a table of the appropriate constants. You'd be far better off using fixed point arithmetic (say x 256) and a table. You only need degrees 0-45, everything else you can derive easily enough.
  12. This is as you say easy enough. The problem seems to be getting back again. It's fine if you crossdevelop as most people are doing, but if it's supposed to work as a standalone system it's a bit ropey.
  13. It's broken really. SCREEN 128:SCREEN 0 doesn't work, for example. It creates a graphic screen on top of the text screen, and starts it at $10000 in VRAM. Problem is there isn't enough VRAM for a 320x200 graphics screen there. Ideally the kernal should work out the screen size from the tilemap sizas and the scaling and the physical limits of the display, whatever L0 is set to.
  14. Progress update, at about 4 weeks as of v0.17 (very alpha) So far : 32 bit integer and string types (hooks for floating point) long variable names. Integer and string functions and operators, BBC Basic style indirection. While/Repeat/For/Multilevel Ifs Procedures Locals/Parameters VPEEK/VPOKE and VDEEK/VDOKE because there are so many 16 bit values. Inline 65C02 assembler Multidimensional Arrays Tokenising / Detokenising, interactive editing, Load and Save from the console. Text I/O functions, Timer function, Event function. Usable Python workflow Next up: Some Sprite commands (X16 specific) Links to the OS drawing commands .... when I can figure out exactly how they work Write a couple of games as a test of the BASIC, the individual tests are somewhat limited. Something like AMAL for the Amiga, a sort of simple scripting language to animate stuff in the background with low resource usage. Floating Point Current module usage. Each module runs through a single link, so it should be possible for example to load it into 2 or 3 pages of $A000 RAM and link it through page switching code without much of a performance hit. Section "header" $1000-$102d (45 bytes) Section "assembler" $102d-$138b (862 bytes) (inline assembler) Section "device" $138b-$14e0 (341 bytes) (I/O virtualisation) Section "error" $14e0-$1815 (821 bytes) (Error messages, multiple languages) Section "extension" $1815-$1924 (271 bytes) (X16 specific stuff) Section "floatingpoint" $1924-$1929 (5 bytes) (floating point routines) Section "interaction" $1929-$1b0b (482 bytes) (the console I/O stuff, program editing etc.) Section "main" $1b0b-$31a8 (5789 bytes) (core interpreter) Section "string" $31a8-$3458 (688 bytes) (string functions/string memory management) Section "tokeniser" $3458-$3c50 (2040 bytes) (tokenise/detokenise program lines) Section "variable" $3c50-$401a (970 bytes) (variables and arrays) Section "footer" $401a-$4100 (230 bytes) Approximate total 12544 bytes.
  15. The VIAs are just used as control ports mostly as far as I can see. The other thing I'm not sure of is the PS/2 interface, which should be on Vera because of the way it operates.
×
×
  • Create New...

Important Information

Please review our Terms of Use