jacobus Posted December 27, 2014 Share Posted December 27, 2014 Jon that is amazing! I always envied the Next for full window dragging - and then played with Windows for hours when it was implemented there! 1 Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 28, 2014 Share Posted December 28, 2014 It looks awesome!! Who needs an actual PCs anymore? Glad, that I could persuade you somehow 1 Quote Link to comment Share on other sites More sharing options...
Joey Z Posted December 28, 2014 Share Posted December 28, 2014 I just wonder how fast all this would be with a HARDWARE blitter like VBXE? I assume that you've designed your soft blitter to be a self contained set of subroutines so they can use the hardware blitter on VBXE if that support ever gets added. Am I correct in that assumption Jon? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 28, 2014 Author Share Posted December 28, 2014 Yeah it's all modular. The blitter is only half the story, of course: much depends on the background windows redrawing quickly. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 28, 2014 Author Share Posted December 28, 2014 Is there a video about this available? I couldn't find something... Finally, I made a short video: At first the ST's hardware blitter is enabled, and then I turn it off. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted December 28, 2014 Share Posted December 28, 2014 >Having lacked energy all week, well - you just reminded me why this project is FUN. That redraw speed is really cool. And as the dragging actually continues while is redrawing, it looks quite natural. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted December 30, 2014 Share Posted December 30, 2014 The hardware blitter on the MEGAs and STEs didn't seem to help all that much...at least compared to the Amiga... *DUCKS* 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 30, 2014 Author Share Posted December 30, 2014 (edited) I'd have to soft-load SuperTOS on my STE to get a true impression: I have no idea how accurately the blitter is implemented in Steem. Burned the A8 ROM to a Maxflash cart this evening and tested it on real hardware for the first time since August (when I first ported the thing to ROM and was half way through writing the kernel). The odd thing is that it feels faster on real hardware. Note: video strobes a bit. Still a few cosmetic issues to fix (mainly owing to auto-refresh being disabled in the process list, resulting in some initial rogue CPU load values), and I really want to get live list scrolling done tomorrow, time permitting. Edited December 30, 2014 by flashjazzcat 10 Quote Link to comment Share on other sites More sharing options...
+Ripdubski Posted December 31, 2014 Share Posted December 31, 2014 Nice work! Quote Link to comment Share on other sites More sharing options...
kogden Posted December 31, 2014 Share Posted December 31, 2014 Awesome! Even has the column-based sorting on the list box working! Will the opaque Window drags be optional? I always found them horribly distracting until things like Quartz Extreme in OSX came along. An impressive technical achievement though. So are things like the filesystem drivers external modules or are they baked into the kernel? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 31, 2014 Share Posted December 31, 2014 Forget all my demo code... This is amazing piece of software... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 31, 2014 Author Share Posted December 31, 2014 Will the opaque Window drags be optional? Yes, absolutely. So are things like the filesystem drivers external modules or are they baked into the kernel? I could have taken a monolithic kernel approach and used syscalls for file operations, but I'll probably follow SymbOS and have filesystem drivers which belong to the system process. Applications just send messages to the system process in order to handle files. The filesystem drivers will be the major job for 2015. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 31, 2014 Author Share Posted December 31, 2014 Live scrolling lists done: That was fiddly to do, and it's still a pretty inefficient implementation which I'll clean up for the demo. I'm not doing any more on this for the rest of the year, though. 7 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted December 31, 2014 Share Posted December 31, 2014 Live scrolling lists done: That was fiddly to do, and it's still a pretty inefficient implementation which I'll clean up for the demo. I'm not doing any more on this for the rest of the year, though. Nice! Next is single-pixel smooth/live-scrolling, right? Quote Link to comment Share on other sites More sharing options...
danwinslow Posted December 31, 2014 Share Posted December 31, 2014 hmm perhaps there's a bit of scrolling OCD going on.... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 31, 2014 Author Share Posted December 31, 2014 (edited) Why not? Single line scrolling should look pretty good. EDIT: Just noticed bug at very end... Edited December 31, 2014 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
popmilo Posted January 2, 2015 Share Posted January 2, 2015 Why not? Single line scrolling should look pretty good. Think it is the most important thing you could do now for Gui Awesome work ! 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 5, 2015 Share Posted January 5, 2015 (edited) I want a demo for the GUI where a dog and a cat watch the mouse pointer move around... if the pointer gets too close to the Cat it takes a swipe at it... If the pointer gets to close to the Dog he takes a bite at it! Glad to see you are concentrating on the 4 C's! I still think about what an O.S. should be and always remember this funny video about winblows 8/8.1 it explains it all and is funny to watch... https://www.youtube.com/watch?v=WTYet-qf1jo http://www.youtube.com/watch?v=WTYet-qf1jo Edited January 5, 2015 by _The Doctor__ 4 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2015 Author Share Posted January 5, 2015 Great video there by Snot from American Dad on why Windows 8 is a pile of crap. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2015 Author Share Posted January 5, 2015 (edited) Busy debugging the memory allocator now. It's based on the page allocator from LNG. I could see no point in writing the same thing from scratch, so I used the Lunix code and modified it to suit our banking strategy. I emailed the author to let him know this some months ago but I never received a reply, and since the LNG page hasn't been updated since 2004, I don't really expect one. But anyway: it's a nice compact allocator and maintains a bitmap of 64 x 256 byte pages. It does best-fit and fast single page allocation (the LNG kernel provides two separate calls for this, while I've combined them so the allocator uses the fastest option depending on the number of pages required). Errors which crept in during modification have been ironed out. Unfortunately all this needs to be finished and working before I can get the RAM stats in the profiler to provide meaningful information. Similarly, the relocator also needs to work so that the loader can place the applications into properly sized chunks of RAM. I've also done quite a bit of work on formatted output, and the list control now clips and centres and blocks right columns: Similarly, the stats at the bottom of the monitor tab are now actual values rather than just dummy text: There are several ways to display formatted numbers. The fastest (for subsequent redraws, if the numbers don't change so often) is to call the kernel's hex to ASCII conversion routine, which will handle 8, 16, 24 and 32 bit values and create a string at a specified buffer, with or without comma-separated thousands. This plain string control is then clipped and blocked right. There's also a formatted numeric string control which does the number conversion every time the dialog redraws, but obviates the need for explicit conversion inside the application. Processes are now properly flagged as applications, shared services, or timers, so I can populate the "Applications" tab as well. I won't get too hung up on finishing too much stuff, since after this demo comes out, the release cycle is going to be a lot faster. What really held things up in the past was constantly running out of code space (hence I had to go away and rewrite the thing so it ran off a cart), but that's no longer an issue and things are progressing at a fair lick. Edited January 5, 2015 by flashjazzcat 9 Quote Link to comment Share on other sites More sharing options...
pixelmischief Posted January 7, 2015 Share Posted January 7, 2015 (edited) Hey Flash, will this project include a memory manager? Something that abstracts away bank switching and allows applications to scale (still only up to the full size of a single bank, I guess)? Along those same lines, do you intend for the resultant software to offer an environment that scales in feature set and performance up to some of the recent big memory sizes and super-fast storage? I know you have been committed to ensuring that the project can run on real, unmodified hardware and I think that is right on. Just wondering if the design leaves those doors open. Edited January 7, 2015 by pixelmischief Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 7, 2015 Author Share Posted January 7, 2015 (edited) If you mean can applications allocate memory dynamically, then yes. And applications never write directly to the bank-switching register (indeed, they never write directly to any hardware). There's no virtual memory, but performance will naturally ramp up the more resources it's possible to keep in RAM at one time. A good example: fonts. They can get quite big (up to 16KB when you get to the 32pt size), and less frequently accessed fonts will be purged from memory when it's required for applications. So if there's ever some application which uses a bunch of large fonts, having a lot of RAM will help. Likewise, if you run everything from a fast hard disk anyway, the pain of loading resources from disk will be lessened. I'm working on the relocating loader as we speak (for MADS relocatable binaries). Getting this working will be a milestone. Edited January 7, 2015 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
danwinslow Posted January 8, 2015 Share Posted January 8, 2015 Jon, whats the basic strategy of that loader? Is there an offset relocation table involved? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 8, 2015 Author Share Posted January 8, 2015 Yes - as per the MADS description here: http://mads.atari8.info/mads_eng.html#_relok The loader's already written but needs testing, and this requires a rough and ready ROMdisk handler which I'm working on now. The loader isn't terribly complex, though. Now, the MADS format is all very nice, but has a few limitations, so I'll probably support a second relocatable file format which loads binaries with relocation tables prepared by assembling at different offsets. A simple command line tool in C shouldn't take long to write. This will at least mean that use of MADS for application authoring isn't absolutely mandatory. Quote Link to comment Share on other sites More sharing options...
danwinslow Posted January 8, 2015 Share Posted January 8, 2015 Yes, the production tool for differing offsets is pretty easy. I'm doing the same myself. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.