Download H.A.R.E.'s HOPPY operating system. Updated 10/07/04 Requirements: CPU: 486 or better (Eventually will be P4 or better when I add MMX instructions)

1.44M Floppy

Graphics: BIOS support for 800x600x16 VGA

Memory: at least 256MB RAM

Recommended: Mouse or Joystick Installation: The file is an exact image of a 1.44M floppy. If you can figure-out how to place it on a floppy, you are probably skilled enough to use it. The program, WINIMAGE, almost works but it has bugs which prevent it from writing the whole floppy. They suck--I paid $60 to them and it doesn't work! I'm not claiming HOPPY is free from bugs ;-) but I'm not charging! Features: Protected Mode operation Non-virtual memory for speed and simplicity Open access at all times to all memory locations and ports C/C++ like command line--No batch/script language to learn "Root" task for permanent, system wide code and symbols Character graphics grid overlaid on graphics Chained hash (symbol) tables allowing reference to functions, variables and all publicly defined elements of the assembly kernel C/C++ compiler for self-modifying code and use in applications during run-time 386 Assembler for altering the operating system Direct block access to drive for efficient database applications No Disk Cache tying-up half the RAM Plans: Currently, my goal is to get a version of grep working which finds and replaces so I can tidy-up names... for instance changing "_node" to "_struct" everywhere. I need to get a pop-up window with buttons which doesn't block the view. I implemented inter-task communication recently, with a plan of spawning a task and calling "do_form" to prompt. Currently, it would take too many keystrokes, so I have to overhaul forms. I already see a problem with my intertask communication mechanism which is contrary to my long term goal of allowing all tasks to be driven by other tasks by spoofing user input. While I may maintain a special case of feeding command line commands to another task and getting a DWORD result, I need to implement message passing similar to windows. (Regardless, I will maintain "root()" and "system()" as special case intertask routines. I plan to have text string messages as though entered from the keyboard, mouse messages, menu choices, scroll-bar and other widget messages. An input message queue is fairly straight forward, however, I'm hoping to have output to the master task. I guess I'll buffer text to putchar and send it to the master when the slave task reenters a loop polling for input. Communication can take place outside these streams by passing a pointer to a slave, like the address of a structure, for "do_form". I'll have a flag to indicate if output text from the slave should be transmitted to the master or not. I need to do a better job of "do_form" with decent widgets, but I plan to avoid resource files as best I can, since they are redundant and slow program development. (I've decided my operating system will be especially liked by developers by sacrificing in some areas to simplify development.) I'm pretty sure I'm going to add doubly-linked list entries to each "linked_text_file" line, creating a collapsible tree data structure which will be flexible. I'll add buttons and the functionality of drop-down lists. (In the class declaration, you'll enter the list choices as a string of zero-terminated choices with a final zero to terminate the enumerated types.) I plan to do most window widgets with text graphics if I can because I'd like to avoid clearing the graphic bit map and redrawing everything, since I wish to maintain persistent graphics (gr_line) for hobbyists. I do not plan to make allowances for foreign language text if it is inconvenient. I wish to keep things simple and I'm not greedy for foreign markets, preferring to let other countries employ their own programmers. The alterations to C syntax in class declarations for forms, represent a inconvenience for foreign languages, for example. Once I have message passing, I plan to implement expanded macros. These macros will be very powerful, allowing sources of data to be inserted during command repetition loops and I'll find a way to call the expression evaluator in macros to allow C expressions. I recently added fault handling, but unfortunately it happens late in the boot process and relies on the system being fairly alive. I don't plan to fix this anytime soon if at all, but I might modify the debug line at the top of the screen with an independent update so debug info (PROGRESS0 PROGRESS1...)gets updated immediately instead of when the window manager gets around to it. I have a problem with occassional spurious keys which i don't plan to fix anytime soon, unless the answer pops into my head. I combined the joystick polling routine with the window manager to avoid lots of little tasks and will come-up with a more sophisticated way to allow routines to be called by a scheduler without creating new tasks. They will have to be fairly short in duration and not interdependent. The "floppy manager" will eventually get called from the window manager. I hope to add really basic support for a printer on the parallel port, perhaps allowing text sent to the screen to be teletyped to the printer and allowing text files to be printed. I'd like to modify the text editor to allow hex editing of binary files and memory locations, but I'll wait until I modify the editor to handle forms. I might decide forms merit separate code, but the binary editing should be doable with the basic structure of the text editor. I need to finish the keyboard scan code translation tables to handle the numeric keypad, but this is a very low priority since I never use the keypad for numbers. I hope to create a richer text format for menu/help files with links and anchors and probably color change escape sequences. This is a fairly high priority. When I have reached a point where I do a version 1.0 release, I need to add extensive on-line help and plan to have enhanced help display before then. I'll probably allow versions of graphic routines which work with client coordinates and clip, in addition to the current versions which work with screen coordinates. Currently, my hard disk driver does not access my whole hard drive. I plan to investigate, but this is a very low priority. I might add IDE disk drive error handling, but this is a low priority. I need to modify the floppy error handling to report just one error per failed track read. I think cd("..") fails on FAT12... this is a low priority. Once I get the tree form done, I'll probably make a file manager and implement file copy and make directory. I probably won't worry about updating all tasks when disk info changes--users will have to be careful. After version 1.0, I might look into TCP/IP, but I have a Microsoft router with propriatary protocol. I'll have to buy a new router first. I might make an Integrated Development Environment eventually and hope to report code size next to each line in the editor. Currently, the assembler/loader is not set-up for programs with absolute addresses. (Since I don't use segment registers in HOPPY, program offsets do not begin at zero, except the operating system itself and the boot code routines.) I might allow for patching absolute addresses during loading, but this would involve a lot of patching. COMPILER replace new_strings with memcpy (format_data)

case statements

do while

recursion/function declarations?

Multidimensional arrays

+= -= *= ect

casting

typedefs

doubles/quads? RTL

optimization: const+mul/div?,register vars,offset[eax*4]

initialize arrays and structs

MEMORY

For MALLOC, move small ones to CACHE instead of leaving in free_list

Garbage collection

ARCHIVE

Compress buffer

Expand buffer

