Barbara Kain Parker, the founder of Standing in Faith Ministries, endeavors to serve others by sharing the faith lessons God has taught her through the everyday trials of life. She is a wife, mother, and grandmother who worked for many years as a registered nurse and as a real estate broker.
A survivor of breast cancer and several other major illnesses, Barbara holds the unshakable belief that God is big enough for any problem that life throws at you. It is this faith that enabled her to work as a hospice nurse, providing comfort to the dying and their loved ones. It is this faith that she writes and speaks about.
A Christian since childhood, Barbara pretty much grew up in church and has served in areas of music, teaching, administration and counseling. She is a prayer minister endorsed by Aslan’s Place, where she often participates as a team member for meetings and webinars.
Barbara is the author/editor/publisher of Pug Parables, I’m Still Standing, and Richard’s Story which are available at Barbara’s Store (all available as free downloads). She also co-authors the Exploring Heavenly Places series with Paul L Cox, available in eBook and print editions at Aslan’s Place. Her webinar, Unraveling the Mystery of Dream Interpretation, is also available at Aslan’s Place.
Barbara speaks to groups of any size, sharing her testimony and teaching others how to stand in faith. She is passionate about the fact that Christians can overcome every difficult circumstance in life through an intimate relationship with God in all three of his persons; Father, Son and Holy Spirit.
Now faith is the assurance of things hoped for, the conviction of things not seen. For by it the people of old received their commendation. By faith we understand that the universe was created by the word of God, so that what is seen was not made out of things that are visible. (Hebrews 11:1-3 ESV)
I love the work being done by Barbara Parker. May the Lord bless the good work she is doing for the master. From Kenya in Africa we want to strongly stand in prayer with her. We appeal to the maker and our King to expand the territories of Barbara’s work.
PICO-8 is deliberately minimal, least of everything. 128x128 screen, palette carefully chosen. But the dev tools are built in. Boots into a prompt. Has a sprite editor, map editor, sound editor in ROM ...
What makes a console a console is not the hardware. It’s the tools, the community, the way it acts as a distribution platform.
I love PICO-8! Unfortunately I haven't had any time to develop anything for it.. (Plus also not being an expert on LUA but how hard can it be. )
I love the look of these games. A few months ago, I briefly wondered whether it might be possible to build a Beeb version using the Pi co-pro and NuLA.
If someone just wants to experiment with the PICO 8 concept, without purchasing the app and further commiting to the platform, there's LIKO 12. It's kind of a clone and can be downloaded for free. I've had moderate success porting to LIKO 12 some short programs from the PICO 8 Tweetjam. These programs are some kind of few-liner mini-demos.
From a retro hobbyist point of view, I'm confident that some of the less demanding code could be rewritten for vintage systems (ditching Lua for assembler, of course).
Hi all, since introducing myself to the board I've been pretty silent but as I've had time I've been chipping away at my project.
Nothing challenging to you old hands but something to help me orient myself with the Model B... In short it's a Flood-it type game. I've something mostly complete now with the core control and input handled in BASIC and the grunt elements in assembly. There's no doubt been an unbelievable amount of unnecessary diversions and wheel reinvention but that seems to be the approach I need to take to learn. Anyhow...
I'm trying to use the RNDX routine to generate the play area, and I've come unstuck... From the BASIC ROM User Guide it appears that I should be able to do this and to some degree I can, in that the numbers I need are generated. The issues become apparent when control returns to the BASIC code. If I contain the calls to 'my' routine in a procedure then I get an 'at line X' message when returning from the proc. X will be the line I call the procedure from. If I keep the call to my code in the mainline code then processing will appear to continue but odd things will happen further into the run. The odd things vary depending on how many numbers I generate.
I've stripped things back to a contained test case. The issue is apparent even when making a single call to RNDX. Can anyone help me determine what's going on?
Although I've stripped away the code (I think) I don't need, this is pretty much the code as presented in the RNDX example of the BASIC ROM User Guide.
Another approach I'm considering is to hack together a routine specific to my case, but I think I'd rather sort this if I can and and move on. As mentioned above this was mostly intended as an exercise to help get me started. I'd be nice to move on to something fresh, though I've no firm plans as to what that might be...
Locations $0004 and $0005 that you write to in your assembler ditty are BASIC's stack pointer so you are trashing its return path for the PROC. This is why lurkio's change works because it gets rid of any PROC and return.
Well spotted! Not sure why the book says to do that. The code works as is if you comment out the offending lines:
That's not "saving" HIMEM in 4/5, it's clearing the stack pointer in 4/5 by setting it to HIMEM. If comments lie like this it's no wonder the code can't be understood. Presumably there's a reason to clear the BASIC stack, but as you've discovered, it destroys any ability to call the code from within a subroutine.
What do you think the reason is, in this context (i.e. when calling the "rndx" routine (&AF24) in the BASIC ROM)?
BASIC has its own stack located immediately below HIMEM. Like the processor stack, it runs downwards in memory. The stack is maintained by a set of subroutines within the BASIC ROM. A stack pointer is held in &4 and &5 (lo,hi). Generally, whenever BASIC has two integer fields to process, one will be located in the IWA [&2A..&2D] while the other is in the stack, pointed to by &4 and &5. When using BASIC routines we shall usually load one integer into the IWA and point &4,&5 at the other.
But that doesn't explain why you should clear the stack in the case of "rndx", which seems to process only one "integer field".
If it's a stack, surely you should update the pointer when you stack a value rather than clearing the pointer back to the beginning of the stack? Otherwise it's not being used as a stack...