Rocky's Boots update RRS feed

  • General discussion

  • I am looking for interesting long term projects for a couple of my advanced kids.  For you antiques out there, how many remember the game Rocky’s Boots?  Has anyone tried to update the program in SB, VB or C#?  I have managed to get the old DOS version to run using DOSBox and I think it is still a pretty cool learning game but it could really use an update.  I need a project like this like I need another hole in my head but I am getting the “I am bored and really need another stupid project” itch.

    • Changed type litdev Monday, March 1, 2010 8:20 PM Discussion on Rock's boots
    Tuesday, January 12, 2010 5:49 PM

All replies

  • That looks like fun.  This site seems to have a good description http://ldt.stanford.edu/ldt1999/Students/kemery/esc/rockyDemoFrame.htm   I read that the author wrote the original Atari Adventure!  http://www.warrenrobinett.com/ 

    I wouldn't mind contributing, I think my kids would enjoy a game like this.  Regarding "I am getting the “I am bored and really need another stupid project” itch" I know what you mean...
    Tuesday, January 12, 2010 9:31 PM
  • I hadn't come across this before.

    You can get an original version with an apple II emulator (ftp://ftp.apple.asimov.net/pub/apple_II/emulators/applewin/AppleWin1.17.2.0.zip) and image (ftp://ftp.apple.asimov.net/pub/apple_II/images/educational/rockys_boots/rocky%27sboots.dsk.gz). 

    Dito bigdadio, I played a couple of the easy levels and looks like fun and ready for a better interface and a decent challenge in SB.  I would be happy to contribute - don't know how a group project would work, but may be fun.

    Tuesday, January 12, 2010 10:53 PM
  • I dug around the internet to see what else is out there for logic gate simulators or games.  No games found but several simulators.  This one is pretty good and comes with the source code in C#.


    Since I do not know a lot of C# it is as clear as mud.  But it does give something to tinker with.  When thinking about this project a bit I can see some major learning will be required.  How to get components to "connect", graphically and logically, and realize they are connected and how to get the boolean logic to "flow" through wires/gates.  I can see lots of arrays in my future and SB is not really array friendly.  This could take a while.  Time to start doodling.
    Wednesday, January 13, 2010 10:12 PM
  • Is there a way to PM (private message) here in the forum, w/o posting email or messenger info?  Would be helpful on a project.  All the projects I've worked on had multiple files, parse out major functions to people, I suppose we can frame it up then dole it out.

    Saturday, January 16, 2010 4:27 AM
  • Here's a first stab to get some ideas going - even this is getting pretty complicated.  Import BNW650.  As usual, the File operations will be commented out at the end of the code doing Save and Load.
    Sunday, January 17, 2010 11:03 PM
  • Wow!!  Nice job man.  I'll install the apple emulator and boots program to see what it's all about, would you like me to do a specific part of this?  I might have a little trouble putting too much into this over the next two weeks, but I'll do what I can.

    We might want to use bitmaps for gates, and have them snap to grid positions, although snapping really isn't necessary.
    Monday, January 18, 2010 5:06 AM
  • Impressive (as usual), LitDev.  I'm interested in feedback about what kinds of new APIs would make this easier to write. 
    Monday, January 18, 2010 9:55 AM
  • LitDev,

    Please take this as a statement of pure admiration, you are scary smart.  It will take me at least a month to figure out what you did in a week.  Cool!
    Monday, January 18, 2010 5:02 PM
  • @litdev:

    If I understand your code correctly, you loop through all components and update a component if all it's input are certain. Then, after you looped through all components, but there are still components left where one or more inputs are uncertain you basically give up on certainty for that component and determine its output if at least one input is certain.

    This way simple combinatorical schematics will always give the correct output immediately, but for schematics with feed-back it can still fail to produce the correct output in one run and require some additional 'spacebar action' to get the correct answer. The standard NOR-based Set-Reset Latch will demonstrate this behaviour.

    You could simply remove the certainty check of your simulation by first updating all components (in any order) and then updating all connectors (again in any order). Doing this places a one-cycle delay on each components, but repeated simulation runs will eventually produce the correct answer. If you state each simulation cycle to correspond to a certain time (say 1 nanosecond) it actually mimics the behaviour of real components which have a certain delay.

    Too Long; Didn't Read version:

    I simplified litdevs code a little: BNW650-0
    It now requires you push the space bar to continue simulation, as opposed to updating automatically when changing inputs.
    Monday, January 18, 2010 8:37 PM
  • ThirdMagus,

    You are right - I did it this way because I didn't have the Space Bar option to start with and I wanted a complete solution calculated in one call with the Return key toggling an input.  Also, loops can mean that there is no consistent solution and the addition of the Space Bar continuous update means your method is simpler and therefore better.
    Monday, January 18, 2010 10:29 PM
  • Vijaye,

    The 3 main methods I (repeatedly) used that are not immediately obvious in SmallBasic are:

    1] Arrays - adding and deleting elements and maintaining a changing list - this works well in this case by always adding an element using a new unique index (incremented at each element addition), then accessing the elements at any time using Array.GetAllIndices. 

    2] Events - I find setting flags in the Event calls, and using these flags in the main code works well - I just have to be careful to check that when an event is processed in the main loop, the flag indicating the event has occurred is reset to show it has been processed.  Doing all the work in a main loop prevents any thread interactions.

    Using the KeyDown and KeyUp events can be tricky since if a key is held down you get one KeyDown event, followed by a pause, then a rapid bunch after the repeat delay is exceeded.  If you want to just know if a key is just pressed once (to trigger a single action) or held down (e.g. arrow keys in a moving game) then a little more processing is needed.  The main issue is not that this happens, but that a new user has to work it out for themselves.

    3] All variables are global so care with use of variable names and subroutines.  This requires good variable naming and plenty thinking about writing subroutines that have clear and simple input and output (i.e. perform a single clear task).
    These 3 work well.  Once discovered, repeatedly using these ideas goes a long way.  They also encourage (require) good structure which is not a bad thing.  What I like is that after a bit of practice the programmer is not limited by remembering lots of commands, but rather by thinking about the problem to be solved clearly.

    I think these ideas and others need good explanation rather than an API change - they are logical, powerful and compact.

    2 things that I think would help are:

    1] Find and Replace - with perhaps exact phrase option to change variable names - good naming helps to make the code clear.

    2] A debugger - major addition, but debugging can be hard using TextWindow.WriteLine and the odd Sound.PlayClickAndWait to try to follow a path.

    In summary, I think all the functionality is there, we just need more and better explanation - I don't know how because people don't want to 'read a book' to get started, but perhaps examples and a set of progressive challenges that highlight what is happening and how to go about doing small tasks effectively and then linking them together.

    Some of the ideas from those using SB to teach and on-line samples and reference may be helpful. 

    One further idea - only if people think it might make things easier to use:

    Along these lines, anything that helps debug, edit and combine prototype ideas into a complete project.  One difficulty is modifying prototype code and combining it into larger projects since variable names are global - e.g. a bubble sort routine needs to be rewritten or at least modified for each project that uses it.

    The extension dll capability could be extended to write extensions in SmallBasic so that the user can create their own generic functions stored in compiled dlls, such as a 'sort utility', or 'mouse over shape detection' etc.  These generic subroutine dlls would require input arguments and return variables and appear in the intellisense just like the C# or VB extensions, except that they could be written in SmallBasic not to add fundamental functionality, but rather to ease the development of larger projects and reusable code.

    Basically, this is like separate code files with static scope, but done carefully in the interface perhaps with a wizard to convert a subroutine to a dll, specifying the input and return arguments and xml description.

    Monday, January 18, 2010 10:33 PM
  • Thanks LitDev.  I'm taking note of all the feedback, so everyone, please keep them coming.  I now have all the pieces in place for building a debugger and I hope to get it done in time for v0.9.  I'll add Find & Replace for v0.9 too (0.8 is effectively done and getting localized at the moment). 

    Creating Extensions using Small Basic sounds interesting - it requires a bit of language work, which is always a time-consuming process.  If I can land an intuitive and non-invasive (existing codebase) approach, I'll definitely give implementation a shot.

    As for learning on the go, I'm interested in ideas.  Someone suggested providing code snippets in the help pane and part of that is coming in v0.8.  I'm not sure how we can help with general good practises like naming variables - ideas are welcome.


    Monday, January 18, 2010 11:01 PM
  • litdev,

    No worries, everybody makes the same mistake ;)
    At my university designing a basic logic simulator is a standard assignment for first-year students. Everybody (including myself :)) initialy attempts to make the solution work in one calculation run. However, the possibility of feed-back makes this impossible. Eventually most people come to the following basic solution:

    Two lists are maintained: a list of components (similar to the one in your solution) and a list of nodes. Nodes are similar to your connections in that they hold a state and connect the inputs and outputs of components.

    The first key difference is that nodes may be connected to any number of components (if we avoid short-circuits this means one output port and any number of input ports), whereas your connections connect only two components (though any number of connections may be attached to a components output port.)

    The second difference is that in your design connections maintain which components it is connected to. In the node-based design nodes hold only a state and the components maintain which nodes their input and output ports are connected to. This makes going through state updates a lot easier because you don't need to loop through all connections to see which are connected to the active component.

    When running the simulation continuous runs are performed, each containing two steps:
    1. Loop through all components and for each component, read the state of the node(s) connected to the input port(s) and calculate the state of the output port(s).
    2. Loop through all components and for each component, update the state of the node(s) connected to the output port(s) to match the state of the port(s).

    Your solution does have several key advantages (which I really like to be honest):
    * It's very easy to make, draw and remove connections and components
    * Any and all logic gates become n-input, and do so very easily
    * No complex wire or node drawing required

    The main disadvantages are:
    * It is impossible to differentiate between different inputs and outputs for more complex symbols (i.e. full-adders, flip-flops)
    * Calculations require looping through all connections to see which are connected for each component

    I'll work on creating a simple example for this alternative implementation, and I hope to have it ready in a few hours.
    Tuesday, January 19, 2010 11:52 AM
  • Vijaye,

    One thing I really miss is functions. I know this discussion has been held before, but I remain a serious advocate of functions. By using subroutines and global namespace the issue of variable scope is avoided, which may be confusing for beginners. But eventually you'll run into a problem which require some form of function to solve. What I usually do now is "emulate" the behaviour of functions:
    'Main program
    AddFunction_Argument1 = value1
    AddFunction_Argument2 = value2
    variable = AddFunction_Result

    'etc... 'Subroutine Sub AddFunction 'Do something with the arguments AddFunction_Result = AddFunction_Argument1 + AddFunction_Argument2 EndSub
    But being able to just say "variable = AddFunction(value1, value2)" would be so much simpler. It wouldn't require me to invent my own namespaces, it would allow for some more advanced programming techniques like recursion and it will promote a somewhat more structured programming style as opposed to a "spaghetti" of goto's. Because Small Basic is primarily intended to teach children and eager students of any age to program I think we should avoid the mistakes of the 70's. Or as Edsger Dijkstra famously said about the early BASIC dialects: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration"

    As for a way of implementing functions without confusing beginners, I think Small Basic could follow the QBasic way:
    'defining a function
    FUNCTION AddFunction(Argument1, Argument2)
      'Do something with the arguments
      AddFunction = Argument1 + Argument2
    In QBasic the result of a function would be defined by assigning a value to the name of the function. Also, a very limited form of scoping was introduced: variables in the main routine could be used only in the main routine, while variables in functions could only be used in that function, unless variables where explicitly defined as global.

    While QBasic also used scoping for subroutines, for backwards compatibility and easing beginners into the principles of scope and functions I suggest keeping subroutines as they are and using variable scopes only with functions.

    I hope my suggestion may be of some use to you, Vijaye.

    reference: A tutorial on subroutines and functions in QBasic:
    Tuesday, January 19, 2010 12:50 PM
  • ThirdMagus,

    I agree with all your comments - I don't have your technical experience in this area and just made a start.

    With regard to the disadvantages you raised, both could be handled by adding more data to the node and connection arrays, such as input connection type and a list of connections attached to any node to prevent looping to find them (easily calculated once in a subroutine and then used as required).

    Setting different input types for more complex symbols would be required if these are added - and how the user would do this is less clear, perhaps if images (rather than ellipse blobs) for components are used, then the different inputs could have different coordinates with the image, again held in the component arrays just as their position, size, type and status currently are.


    Definitely, images are needed and they may need to be rotated somehow - the component arrays already hold the shape width and height and the colors[] array needs to be deleted/replaced with an array of images.

    Also I like the snap-to-grid idea which should be easy in the Move() subroutine - harder is showing a grid, since the connections are currently drawn on the background and cleared for each redraw - perhaps use shapes for the grid which lie above the background layer and won't need redrawing with the connection arrows.
    Tuesday, January 19, 2010 9:13 PM
  • The promised alternate implementation: BNW650-1

    The node-based structure is now used. Components now have a fixed number of inputs. Input and output ports are made visible. OverComponent() has been modified to also return the specific port that was selected (in a rather crude way, but it works.)

    Nodes are not drawn seperately, in fact, the list of nodes currently mirrors the list of components exactly as every component available at the moment (except the Output component) has exactly one output port, and only one node is required.

    Input and output ports are currently drawn with routines directly based on the type of component, but this really should be changed so ports are specified in the component data.


    I completely agree, images of gates and some form of grid should be next on the feature list. Then, eventually, some nice fancy routable wires, and of course the game logic this thread was all about in the first place ;)
    Tuesday, January 19, 2010 10:03 PM
  • Cool, Rocky's boots are growing legs. Nice work - I look forward to images, grid, game logic ...
    Tuesday, January 19, 2010 10:24 PM