Joey Z Posted December 6, 2012 Share Posted December 6, 2012 (edited) Hah ha, Joey not you tooo!.... You guys really need to re-read some of the stuff I have written. Maybe BOLD CASE WILL STICK OUT BETTER. I NEVER SAID IT'S NOT POSSIBLE, I SAID IT'S NOT WORTHWHILE THE EFFORT AND I REPEAT IT AGAIN DESPITE THE AMSTRAD DEMO with nice looking girls shaking their butts against a backdrop of Pacman chasing ghosts. If you don't believe me, just wait, and our lifespans permitting, we will see the results... OK fine, then while I could probably search here and find a quote where you called it impossible, it doesn't matter. my point is, YOU shouldn't care if OTHER PEOPLE 'waste' THEIR time on this. EDIT: or maybe I can't find a quote where you called it impossible (I did say probably the first time) Edited December 6, 2012 by Joey Z 1 Quote Link to comment Share on other sites More sharing options...
atari8warez Posted December 6, 2012 Share Posted December 6, 2012 (edited) OK fine, then while I could probably search here and find a quote where you called it impossible, it doesn't matter Well that's how urban legends spread like wildfire.... . my point is, YOU shouldn't care if OTHER PEOPLE 'waste' THEIR time on this. EDIT: or maybe I can't find a quote where you called it impossible (I did say probably the first time) But I am a caring person Edited December 6, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
LoTonah Posted December 6, 2012 Share Posted December 6, 2012 Hey, Flashjazzcat. You'd better cancel the whole thing because atari8warez thinks this is a waste of time. Glad he spoke up before you went any further. Maybe you should go watch some TV and never try to do anything amazing ever again. /please see the sarcasm in that! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 6, 2012 Author Share Posted December 6, 2012 9 Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 6, 2012 Share Posted December 6, 2012 BTW, does SymbOS run on anything other than an Amstrad? It has been ported to the MSX2 (Screenshot) and Joyce PCW (Screenshot) (also an Amstrad but a complete different machine, not compatible). Due to the better hardware the MSX-version is more powerful than the CPC and PCW version. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted December 6, 2012 Share Posted December 6, 2012 It has been ported to the MSX2 (Screenshot) and Joyce PCW (Screenshot) (also an Amstrad but a complete different machine, not compatible). Due to the better hardware the MSX-version is more powerful than the CPC and PCW version. OK. I was just curious since I am in the process of building my own Z80 based machine. while it will obviously start off simple and primitive, I may eventually add graphics hardware, RAM banking, etc. as I understand it, the topmost parts of the OS are written mainly independent from the hardware. so my questions are: is it possible to port this to a completely different custom machine or am I out of luck? if yes, what are considered the 'minimum' requirements of a Z80 system that is capable of running SymbOS? If I were to do this, would it be a lot easier if I tried to make various features (things like banking) similar/identical to the CPC, the PCW and/or MSX? Lastly, should I have sent this to you in PM so as to avoid hi-jacking the thread? (question for others/FJC) Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 6, 2012 Share Posted December 6, 2012 OK. I was just curious since I am in the process of building my own Z80 based machine. while it will obviously start off simple and primitive, I may eventually add graphics hardware, RAM banking, etc. as I understand it, the topmost parts of the OS are written mainly independent from the hardware. so my questions are: is it possible to port this to a completely different custom machine or am I out of luck? if yes, what are considered the 'minimum' requirements of a Z80 system that is capable of running SymbOS? If I were to do this, would it be a lot easier if I tried to make various features (things like banking) similar/identical to the CPC, the PCW and/or MSX? Sounds interesting What SymbOS requires is... - a Z80 CPU (or compatible like the R800 in the MSX turboR) - 128KB or more Ram (no Roms are required) - a 50Hz (or faster) hardware interrupt signal - special RAM banking possibilities: It should be possible to swap each of the 4 x 16K in the visible 64K area (0-3ffff, 4000-7fff, 8000-bfff, c000-ffff) with any other 16K block in the whole memory (max. 1MB); this is how the MSX and the PCW are doing it - bitmap screen mode (2, 4 or 16 colours) ...and of course some keyboard/joystick or mouse and disc drive/harddisc. SymbOS only supports the FAT12/FAT16/FAT32 (up to 128GB) and the Amsdos + CP/M filesystem. It would be great, if the video hardware has some blitter functionality like the VDP of the MSX2 has. Because of this SymbOS runs faster on an MSX than on a CPC as the lowlevel-screendriver can then be optimized. But yes, we should move to PM for everything else - sorry for off-topic! Quote Link to comment Share on other sites More sharing options...
LoTonah Posted December 6, 2012 Share Posted December 6, 2012 http://youtu.be/x3i4I5KXnsY Laughed so hard I woke up my wife. It was worth it! 1 Quote Link to comment Share on other sites More sharing options...
+DarkLord Posted December 6, 2012 Share Posted December 6, 2012 Ditto. Well, I didn't wake my wife up but really do appreciate the fact that flashjazzcat can still keep his since of humor, even after all this time and effort...(not even mentioning criticism and abuse) Quote Link to comment Share on other sites More sharing options...
Tezz Posted December 6, 2012 Share Posted December 6, 2012 haha wow, coding, hardware, musician and, impressionist! Is there no end to your talents Jon? I've said it before but, it's a fantastic professional approach to such a big project. It takes guts and patience to keep assessing what you're doing and continually rewriting from trial and testing. The end result will be outstanding 7 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted December 7, 2012 Share Posted December 7, 2012 (edited) I just found it was a good decision not to try and keep up with this thread for a while. One one hand I got my SV release done, on the other hand it's really more entertaining if you can read all this at once :-) Regarding speed, stacks and ZP: (Level 3 Demo Coder's answer) Assuming we have enough space to unroll the code (e.g. we have the cart), you can brutefore copying the $80 byte of ZP and the full stack to the extended RBAM bank in <3000 cycles with LDA/STA, e.g. less then 10% of a frame. Even much less if you use the current stack pointer as index in the unrolled code for the stack pointer part. And as for the nice text mode demo video: Seems we can then finally control the machine with the keyboard and don't have to use the mouse all the time! Edited December 7, 2012 by JAC! Quote Link to comment Share on other sites More sharing options...
atari8warez Posted December 7, 2012 Share Posted December 7, 2012 (edited) <media goes here> Wow, I am speechless , must admit it's creative to say the least.... As for groundbreaking, earth shuttering news on AspeQt.... not really.... I am still trying to figure out why SDX drops the first sector of data when copying from a source file from the folder image to the target file. Interestingly this only happens when the target disk is in SpartaDos format. With a target disk in Atari DOS format everything is fine. I am not sure at this point whether this is SDX or AspeQt related. Need more testing and some hard debugging which requires some serious concentration on my part which I seem to be lacking these days...and the fact that 90% of undocumented AspeQt code doesn't belong to me does not help a lot in debugging Edited December 7, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 7, 2012 Share Posted December 7, 2012 As for groundbreaking, earth shuttering news on AspeQt.... not really.... I am still trying to figure out why SDX drops the first sector of data when copying from a source file from the folder image to the target file. Interestingly this only happens when the target disk is in SpartaDos format. With a target disk in Atari DOS format everything is fine. I am not sure at this point whether this is SDX or AspeQt related. Need more testing and some hard debugging which requires some serious concentration on my part which I seem to be lacking these days...and the fact that 90% of undocumented AspeQt code doesn't belong to me does not help a lot in debugging Good luck with that. I am spoiled by the nice debugger in VS2010, but so much of the coding I do is database related. That is never fun to debug (is anything?) Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 7, 2012 Share Posted December 7, 2012 Regarding speed, stacks and ZP: (Level 3 Demo Coder's answer)Assuming we have enough space to unroll the code (e.g. we have the cart), you can brutefore copying the $80 byte of ZP and the full stack to the extended RBAM bank in <3000 cycles with LDA/STA, e.g. less then 10% of a frame. Even much less if you use the current stack pointer as index in the unrolled code for the stack pointer part. Don't forget, that you have to do this twice on each task switch (saving the current ZP/Stack and restoring the next ZP/Stack). A task switch should happen at least once per frame. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 7, 2012 Author Share Posted December 7, 2012 (edited) I just found it was a good decision not to try and keep up with this thread for a while. Unfortunately I've has similar feelings of late. Assuming we have enough space to unroll the code (e.g. we have the cart), you can brutefore copying the $80 byte of ZP and the full stack to the extended RBAM bank in <3000 cycles with LDA/STA, e.g. less then 10% of a frame. Even much less if you use the current stack pointer as index in the unrolled code for the stack pointer part. I was gonna grab some time this weekend in between driver writing to adapt a version of Tebe's sample code in order to try and establish these very statistics. So this is great info, Peter - thanks! And as for the nice text mode demo video: Seems we can then finally control the machine with the keyboard and don't have to use the mouse all the time! Amazingly some people prefer to navigate dialogues with the keyboard even when mouse support is provided. Those that don't should just avoid touching the keyboard, of course. A task switch should happen at least once per frame. Another question answered before I had to ask. ...which requires some serious concentration on my part which I seem to be lacking these days... No wonder, since you spend so much time fooling around in this thread. Edited December 7, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
potatohead Posted December 7, 2012 Share Posted December 7, 2012 I am one of those keyboard people. I do it to avoid a context change on input. Please support both. Re: ballsachery Jon, just build it. Fuck'em. Your baby, nobody else's. Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 7, 2012 Share Posted December 7, 2012 Don't forget, that you have to do this twice on each task switch (saving the current ZP/Stack and restoring the next ZP/Stack). A task switch should happen at least once per frame. Hmm - 20% of the frame just for the stack? That's disappointing. Maybe this will take much less time if only the relevant bytes need copied? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 7, 2012 Author Share Posted December 7, 2012 I am one of those keyboard people. I do it to avoid a context change on input. Please support both. Without hesitation. That's why we've got the shortcut keys displayed in the menus (they just don't do anything yet). Re: ballsachery Jon, just build it. Fuck'em. Your baby, nobody else's. Well, it should be apparent that I stopped paying attention to the crap some days ago. However, my tolerance will easily be exhausted if the problem becomes chronic. This wouldn't affect the development process, just the means by which it's documented. Hmm - 20% of the frame just for the stack? That's disappointing. Maybe this will take much less time if only the relevant bytes need copied? It'll certainly take less time, and moreover I don't think we're talking about a large chunk of the stack, nor page zero for that matter. The thing about the stack is it needs to be flexible, so there's no point in segmenting it into small, fixed size partitions. Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 7, 2012 Share Posted December 7, 2012 (edited) Another question answered before I had to ask. TBH the rule "at least one task switch per frame" is what I heard somewhere in the past (IIRC someone told me that Windows is doing it like this), and that's also how I do it in SymbOS. Maybe 25Hz would be ok, too (but in this case, the GUI task can't react on keyboard/mouse inputs as fast as we are used to it [50Hz]) In reality you don't have much more than 2 or 3 working tasks at maximum, most tasks are in sleep or in idle mode. Those tasks, which are idle, return to the scheduler at once - in this case you have more than one switch/frame even if the scheduler is forcing a switch only once per frame. But here again: Idle tasks shouldn't use much of the stack and the zero page, so you will have a fast task switch in this case. Edited December 7, 2012 by Prodatron 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 7, 2012 Author Share Posted December 7, 2012 (edited) In reality you don't have much more than 2 or 3 working tasks at maximum, most tasks are in sleep or in idle mode. Those tasks, which are idle, return to the scheduler at once... Well, this is the salient point about GUIs which it seems not everyone grasps. On the Atari in 2 colour hi-res mode, the likelihood of running tasks (e.g. video players) relentlessly drawing to the screen without taking breath is lessened. From what's been done so far, it's clear to me that the most cycle-intensive operations are screen updates, pure and simple, and I'd be inclined to give redraws a high task priority anyway. The single-tasking demo is, of course, doing next to nothing for half the time (except servicing the interrupts which poll the mouse and draw the pointer) until a window is moved or client area content changes. So why not put those "dead" cycles to good use? "Parallelism" was talked about much earlier in this thread, for precisely the reasons outlined here. Edited December 7, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+DarkLord Posted December 7, 2012 Share Posted December 7, 2012 Jon, if/when you manage to implement multitasking successfully, if its apparent "speed" is a subjective thing, (as in some people feel its fine, others feel its a bit slow, etc, and I guess that would differ entirely based on what kind of software people are trying to use on it, based on their needs/prefs), are you planning on making it configurable? As in, per user choice, they could turn multitasking *off* entirely, but keep the rest of the GUI working? I'm assuming you'll have some kind of manager for it, where you can kill process's, prioritize them, etc,... If this has been discussed/answered already, I apologise, hard to glean the chaff from the wheat in this thread sometimes... Thanks! Quote Link to comment Share on other sites More sharing options...
atari8warez Posted December 7, 2012 Share Posted December 7, 2012 (edited) No wonder, since you spend so much time fooling around in this thread. Actually the reason I spend so much time around this thread is due to factors other than my curiosity about this project. I would normally be only reading it quietly had it not been for the relentless reaction I see from you and other readers to some of my comments. Apparently one can not express his opinion freely if the opinion brushes the developers feathers in the wrong direction. We all see the type of replies I get from various people here and I would say very few falls into what i would call a technical discussion (i.e.: "Jon, just build it. Fuck'em....."). I am being seen as negative, alleged to have said things that I haven't etc...etc... In any case the best approach from me from now on would be just to keep quite, keep my opinion to myself, and wait and see. That's what I should have done in the first place anyway because the strongest word on this subject would be the end result of this project, and I am hoping to live long enough to see that day. Edited December 7, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
atari8warez Posted December 7, 2012 Share Posted December 7, 2012 (edited) Good luck with that. I am spoiled by the nice debugger in VS2010, but so much of the coding I do is database related. That is never fun to debug (is anything?) Thanks....Qt IDE also has a nice debugger (but I am new to Qt and C++), the difficulty is in debugging multi-threaded, event driven code. AspeQt code that listens to and serves SIO requests is run in a separate thread outside of the GUI and it's completely event driven. In the good ol' days programming was done in a top-down fashion where the code followed a certain flow and logic so tracing the code during debugging was much easier. Not quite so with the newer technology and I am not in my early 20's anymore Edited December 7, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 7, 2012 Author Share Posted December 7, 2012 The only way to please everyone (well, nearly everyone) is to make almost everything configurable, and certainly no-one will need to feel compelled to open more than one application at a time. If the pre-emptive route is chosen, I'll follow SymbOS's method of having the UI manager itself running as a parallel task to whatever application (this seems like sensible design to me, and - as Prodatron already explained to me - passing messages between applications and the desktop manager neatly solves the issue of re-entrancy, which is naturally hard to support in assembly language). So, in a single-application scenario, you'll basically have the I/O process and the UI manager process idling the whole time (i.e. immediately calling idle when they find no waiting messages in their queue) until something happens - i.e. you drag a window in your single application, causing a series of messages to be exchanged between UI manager and application. I'd envisage that while the redraws are happening, the application would tend to be idling while the UI manager was busy, and vice versa. So I can't see the overhead being great if you elect not to have non-idling applications running in the background. Surely if an idle process has no messages waiting, the context switch into that process need not even be attempted, so we save time there too. So, in short, if I/O, UI and application (the minimum three processes required for the system to operate) are implemented as parallel processes (necessary if pre-emptive tasking is implemented at all), it won't be possible to just flip a switch and pretend the facility isn't there, but I doubt this design will significantly degrade single-application operation. Yes, we'd be able to kill processes and assign them priority. There's nothing to stop really screwed up applications from writing outside their memory space (ostensibly, $4000-$7FFF), but if a program simply went into a closed loop for some reason and stopped pulling messages out of its queue, it would be classed as "unresponsive", and we'd be able to kill it, which is nice. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 7, 2012 Author Share Posted December 7, 2012 In any case the best approach from me from now on would be just to keep quite, keep my opinion to myself, and wait and see. This would be a wonderful contribution to the thread and to the project as a whole. Thanks in advance. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.