<veltas>
kori: The keyboard for ZX Spectrum is not that bad IMO, but the token typing (instead of character typing) for BASIC is annoying
<veltas>
Kumool: awesomerc.lua is an attempt to use Lua as a config file format, and it's really bad. I don't know what the personal goals of awesomerc.lua were but either they failed or totally missed the point.
<veltas>
That message on the mailing list is not "how you build a DSL in Lua", that is someone asking for a specific syntax that does not work well with Lua's built in sugars, customisation, but it was still relatively easy to parse with the built-in matching features
iyzsong- has quit [Read error: Connection reset by peer]
iyzsong has joined #forth
iyzsong has quit [Read error: Connection reset by peer]
<veltas>
tpbsd: The way I would do NOR Flash for Forth is to keep an area for just writing an index of where the latest versions of each block index is, and then for the rest of the erasable area write out copies of each block each time it is written back to storage
<veltas>
So you are only erasing when the area runs out of space for these copies, the simulated 'max' size of the area is about half of the Flash size
<veltas>
And you get some wear levelling because it's writing over the whole thing before each erase
iyzsong has joined #forth
<tpbsd>
veltas, the way I do it is use the hflash! command :)
<tpbsd>
I'm just a Forth user, I dont write forths
<veltas>
Don't search for "hflash!"
<veltas>
I just found out that was a bad idea
<tpbsd>
I used that command recently when I released a diagnostics program for 'blue pill' board owners
<tpbsd>
among other things it tests a 64kB block of flash by writing to every location
<veltas>
Why is it called 'blue pill'?
proteus-guy has quit [Ping timeout: 260 seconds]
<tpbsd>
it's a small pcb that's coloured blue
<tpbsd>
probably a oblique reference to 'the matrix' film as well ?
<veltas>
There is a Matrix reference in there somewhere I think yes
<tpbsd>
I dont know, I dont even own one
<tpbsd>
but they are really cheap
<tpbsd>
usually $2
<tpbsd>
but they have some serious problems one of which is they tend to come with fake STM32F103 MCU's
<tpbsd>
my program designed to interrogate the mcu and help find out what it was
<veltas>
Interesting
<tpbsd>
to date I've had about 150 downloads of my binary presumably by blue pill owners
<veltas>
Nice
<tpbsd>
it's become a bit boring now as Ive learnt a lot about whats happening with that product, which was a mystery to me initially
<tpbsd>
I made the self booting binary with Forth, which was the perfect OS to do it in
<veltas>
Nice
<tpbsd>
we have a Forth USB driver for that board so all the owners needed to do was plug in in and connect a serial terminal to the virtual com port
<tpbsd>
checkout the USB ID string "Mecrisp STM32F10x Forth Serial Port"
<veltas>
Interesting
<veltas>
crc: If I am understanding repl.c correctly your dictionary has 4 fixed position fields "link", "xt", "class", "name". What is "class"? Is that whether it's immediate or not?
<veltas>
Also what is the "xt" literally in your forth?
<tpbsd>
Word classes are one of the two elements at the heart of
<tpbsd>
RETRO’s interpreter.
<tpbsd>
There are different types of words in a Forth system. At a
<tpbsd>
words.
<tpbsd>
minimum there are data words, regular words, and immediate
<tpbsd>
I'm still not used to different namespaces, I still find them too wordy
<tpbsd>
and Mecrisp-Stellaris doesnt have them as it's for small mcu's
<tpbsd>
wheras retro is generally used on a PC where there are tons of every resource
<tpbsd>
veltas, my diagnostics program has to be under 64kB with everything, and there are no alternatives except perhaps Basic which few use now
<tpbsd>
eLua needs at least 256kB just to run, so it's no good for that kind of application
<tpbsd>
same with micropython etc
<veltas>
I am working on 8-bit stuff at the moment
<tpbsd>
yeah, Z80
<tpbsd>
I have made product with the Z80 in the past, written the code in C
<tpbsd>
oops assembler I mean
<tpbsd>
that was around 1982 I think
<tpbsd>
i made thousands of Z80 boards for one product once
rdrop-exit has joined #forth
<tpbsd>
lol, and a decade later I saw a box of the same boards at a auction, and didnt recognise them at first
<veltas>
What did they do?
<tpbsd>
they did a couple of things. They were used in commercial video games, the kind of machines you see in video game parlours
<tpbsd>
1) reset the game if a static charge was detected on the metal coin box
<tpbsd>
2) if 2 coins were entered before the start game button was pressed, add a free credit
<tpbsd>
something like that
<tpbsd>
may have been a free credit for every 2 coins and two free credits for 10 coins etc
<tpbsd>
in those days the kids playing the games would use a piezo electric gas lighter to spark into the metal coin box to glitch the game and try to get free credits
<veltas>
Okay
<veltas>
'ok'
<tpbsd>
it worked pretty well, and they could glitch thousands of extra credits
<veltas>
So not that well then
<tpbsd>
there was a lot of TTL still in the games at that time
<veltas>
TTL?
<tpbsd>
and TTL was a real problem with spikes
<tpbsd>
Transistor Transistor Logic
<veltas>
Oh right
<tpbsd>
it was replaced with CMOS eventually (thank God)
<tpbsd>
so my Z80 board would also detect the spike and reset the game, goodby all credits
<tpbsd>
it was a nice project, simple, reliable
<tpbsd>
and the board was retrofitted into thousands of games
<tpbsd>
good old Z80
<tpbsd>
I wrote the code on a TRS80
<tpbsd>
i still recall it's brand new smell as I unpacked it at work
<tpbsd>
plus the manuals etc
<tpbsd>
the Z80 was a Godsend at the time, but I'm not nostalgic about it
<tpbsd>
I always loved the 6800 myself
<veltas>
Z80 is really dirty
<tpbsd>
and now it's all cortex-m or msp430 for me
<veltas>
6502 is pure but really verbose
<tpbsd>
although I have a couple of hundred PIC18 and PIC24 series chips
<tpbsd>
yeah, 6502 is much like the 6800, in fact designed by some guys who worked on the 6800
<veltas>
I know what you mean
<tpbsd>
there is still a lot of 6502 love about I see
<tpbsd>
Ive never used it myself, tho Ive repaired plenty of Atari games boards that use the 6502
<veltas>
Well it is credited as being the RISC genesis
<tpbsd>
yet it's not risc itself ?
<tpbsd>
it has plenty of instructions
<veltas>
It doesn't match the description of RISC
<veltas>
It doesn't have that many instructions
<veltas>
But it does a lot of memory operations, the typical RISC will do everything in registers and explictly separate out loads and stores
<veltas>
6502 has 1 GPR so that is not really an option
<veltas>
Zero page instructions treat the first 128 words like psuedo-registers, so that is the link I think
<veltas>
Coding in 6502 feels like coding for a RISC processor with 128 16-bit registers
<veltas>
Are there forths where R> DROP EXIT does something meaningful?
<veltas>
Like where e.g. you put a previous return value in there
<veltas>
and you get to go back to where it was interpreting before?
john_cephalopoda has quit [Read error: Connection reset by peer]
john_cephalopoda has joined #forth
gravicappa has quit [Ping timeout: 255 seconds]
<tabemann>
veltas: in many Forths that's an ugly way of doing a branch
<tabemann>
well wait
<tabemann>
that's R> DROP >R EXIT
<tabemann>
R> DROP EXIT isn't very useful because it only exits to the thing that called the caller if the caller put nothing on the stack aside from its return address
<veltas>
How common is it that this can do a branch?
<tabemann>
it typically can from what I gather, but I'm not sure if it's something you want to do
<veltas>
hmmm
<veltas>
Well just relevent to me now deciphering how I will implement my forth
<veltas>
I have a better(?) question, reading Starting FORTH, it refers to a "code pointer" in each dictionary entry, preceding the parameter field
<veltas>
Is that a pointer to machine code or a pointer to a colon definition's parameter field?
<tabemann>
I wouldn't even think about that
<tabemann>
like the Forth I'm developing right now lacks that
<tabemann>
a code pointer is basically a thing in indirect threaded Forths
<tpbsd>
hey tabemann when you have the basics of your Forth running, I'll make you a svd2forth for your stm32l476
<tabemann>
but yeah, in zeptoforth words are described one of two way - as a pointer to their header, or as a pointer to the code itself (the 'xt')
<tabemann>
tpbsd: thanks!
<tpbsd>
tabemann, be my pleasure
<tabemann>
I'm annoyed that I can't get writing to Flash to work for some reason
<tpbsd>
thats one of the harder parts of some STM32's
<tabemann>
even though my Flash writing code is basically identical to Matthias's in its basics (because I essentialy copied it from him verbatim, complete with copyright attribution)
<tpbsd>
just be glad you didn't pick a Atmel SAM Cortex-M
<tpbsd>
perhaps run up matthias code and look at what it's doing via GDB ?
<tabemann>
and I know that flash writing works under Mecrisp-Stellaris for STM32L476 because I tried it before successfully
<tpbsd>
then check against your own code
<tpbsd>
sure, but he also battles with flash on new chips
<veltas>
tpbsd: That looks very relevant to me, thanks
<tpbsd>
most C users never have to bother, they flash their binary via openocd and thats it
<tpbsd>
veltas, Brads page is a kinda defacto for people writing their forths
<veltas>
tabemann: Refer to the flash spec maybe?
<veltas>
spec/datasheet
<tabemann>
"refer to the spec" isn't very useful in all cases when you consider just how much spec there is to deal with
<tpbsd>
tabemann, that error is generated by Mecrisp-Stellaris for the following reasons
<tpbsd>
Is the desired position in the flash dictionary? Outside the Forth core
<tpbsd>
Check the address: it must be even on 2
<tpbsd>
Is -1 at the desired location in the memory ? <-- thats your $F check
Kumool has joined #forth
<tabemann>
-1 indicates unwritten memory
<tpbsd>
yes, erased state
<tabemann>
or at least four words containing -1 in a row
<tpbsd>
$FFFFFFFF
<tpbsd>
yeah half word
<tabemann>
I was suspecting it might have been my boot-up code not properly initing the flash, but my boot-up code looks kosher too
<tpbsd>
must be hard to debug at that stage ?
<tpbsd>
youre only working is assembly atm ?
<tpbsd>
is = in
<tabemann>
this is all asm
<tabemann>
I do have gdb though
<tpbsd>
yeah, fully non interactive asm
<tpbsd>
you know what you can do ?
<tabemann>
well it has to bring up the driver code
<tabemann>
zeptoforth is now interactive though
<tpbsd>
lol, install free rtos and then run Mecrisp-Stellaris as a task
<tpbsd>
develop zapyou Forth in another task
<tabemann>
I tried running mecrisp-stellaris today, and the same test that I ran on zeptoforth which failed on it passed on mecrisp-stellaris
<tpbsd>
I'm not surprised even tho matthias code is beautifuly written imho
<tpbsd>
something may well be tucked away somewhere not obvious
<tabemann>
I basically took his code directly, that's the thing
<tpbsd>
well obviously you missed something
<tpbsd>
his works, yours doesnt
<tabemann>
(most of zeptoforth is written completely independent of mecrisp-stellaris; it's only the "driver" code that's copied
<tabemann>
)
<tpbsd>
sure, not that matthias would care
<tabemann>
matthias actually told me it was fine if I used parts of stellaris-mecrisp
<tpbsd>
I've spent weeks analysing his code just to understand how some things work
<tabemann>
(after all, he did license it under the GPL, as have I for zeptoforth)
<tpbsd>
of course, he's not precious about it
dave0 has joined #forth
<tpbsd>
he would love to hear someone using some of his code in their own Forth
<tabemann>
my only thing is that I wish he had licensed his code as BSD, so I could also license my code as BSD
<tpbsd>
it's not like hes swamped with emails asking if it's ok
<tpbsd>
so do I actually
<tpbsd>
but then we have what we have
<tpbsd>
GPL is better than no code
<tpbsd>
and once you fully understand what youre doing, you can rewrite the bits you copied
<tpbsd>
and relicense
<tabemann>
the problem is that his code appears to be The way to do things
<tabemann>
so it'd be hard to rewrite
<tpbsd>
for instance, I can use any license I like with the output from his "mecrisp-Across"
<tpbsd>
yeah, there is that also, his insights are like a laserbeam
<tpbsd>
matthias isnt just good at this stuff, he is devastatingly good, hes the God of Assembly thinking
<tabemann>
my problem here is I have eliminated all the places where the flash-write code differs from matthias's, and it still doesn't work
<tpbsd>
no you havent
<tpbsd>
if you had, then yours would work
<tpbsd>
you may have 'exhausted' all the differences you can find, and I do appreciate how frustrating that is
<tpbsd>
I have had MASSIVE "aha" moments after spending days/weeks tracking down what Matthias has done
<tpbsd>
perhaps some command youre using isnt writing a register as you assume ?
<tpbsd>
perhaps a sequence order is critical ?
<tabemann>
I write the very same registers as he does, in the same order, the only thing I can think of is that I wrote a constant wrong or something, but that I haven't been able to find
<tpbsd>
as a direct result of our convo here today I looked thru matthias flash code for my stm32f051 and found it quite straightforward
<tpbsd>
and it inspired me to include the reasons for his error in my online doc
<tpbsd>
hmm the flash assy for your mcu doesnt look much different to the code for my M0
<tabemann>
back
<tabemann>
YES
<tabemann>
I figured out the problem
<tpbsd>
awesome!
<tabemann>
it was totally nonobvious
<tpbsd>
as expected!
<tabemann>
it worked after I turned off gdb and openocd and attached ran it without them
<tpbsd>
ah crap!
<tpbsd>
thats a real gotcha!
<tabemann>
I know!
<tpbsd>
so looks like gdb doesnt solve *all* problems
<tpbsd>
I had the opposite problem recently
<tpbsd>
due to a STM32F1xx problem, reading the DBG registers only works when the debugger is ATTACHED
<tpbsd>
you can then remove it and still read the DBG registers, but after a POWER reset, those registers are unreadable
<tpbsd>
ironically, tho this was never fixed by STM with a respin, the clone makers fixed it
<tabemann>
back
<tabemann>
yeah you told me about that
<tpbsd>
all in all, I VASTLY prefer to do my debugging in Forth
<tpbsd>
hey could you use a .equ file with every register in your MCU ready for gasm ?
<tpbsd>
it's this format ( this is for a GD32VF103 risc-v chip)
<tpbsd>
.equ ADC0_BASE, 0x40012400 @ (Analog to digital converter)