00:00:00 --- log: started forth/20.06.03 00:21:43 --- join: xek__ joined #forth 01:18:26 --- quit: xek__ (Read error: Connection reset by peer) 01:18:39 --- join: xek__ joined #forth 01:41:15 --- join: xek_ joined #forth 01:44:10 --- quit: xek__ (Ping timeout: 272 seconds) 02:42:22 Anyone been paying attention to this cool retro project that seems to be gaining traction? https://rc2014.co.uk/ 02:48:57 it's amazing how programmers love retro projects. As a electronics tech I had to build and fix gear with Z80's in the early 1980's and I'd perfer to not see another one. To me it's like buying a Stanley Steamer instead of a Tesla 02:49:42 Ive fully embraced the latest MCU's with Forth and I feel like I'm living in the Golden Age of Microprocessors now 02:50:29 proteusguy: Seems interesting, haven't heard about it. 02:51:42 The BASIC must surely be interpreted. 02:57:05 yes of course - as it was back then. 02:57:24 siraben, you should get your forth running on that z-80. :-) 02:58:01 tp, someone did a 6809 board for it. Nothing about it is specific to z-80. 02:58:31 Haha, wouldn't be hard to port my Forth at all. 02:58:48 proteusguy, it's just me and the fact I was there then and had to work with them. Same with the 6809 02:59:30 for those that only know then from history I understand there may be some retro alure 03:00:04 it's probably the same with everything 03:01:02 Wait a few decades and we might see retro projects on x86 03:01:02 i remember the 6809 came out in the more advanced commercial video games like 'defender' 03:01:44 I guess the games manufacturers were waiting on something more advanced than the z80 for those kind of games 03:02:19 --- join: dddddd joined #forth 03:06:01 I loved the 6809. 03:06:47 I really didn't like Z80. 6502 was ok but funky but I was an Apple ][ hacker. 68000 was pretty nice but 6809 was the sweet spot for 8 bit for me. 03:07:15 siraben, no one feels nostalgic for any of the x86 machines... 03:07:31 nasty instruction set architecture. 03:07:40 proteusguy: Indeed 03:08:18 ARM's pretty nice IMO, the three argument instructions are good for compilers to work with. 03:10:40 I just never could like ARM. RISCV is a serious improvement but I still don't love it. I also loathed PIC & 8051 but liked Atmel a lot. 03:10:50 Naturally much of that is personal taste. 03:11:58 Agreed regarding RISC-V, althought it still needs to mature a bit more. 03:15:30 boru, I'm slightly concerned that they're standardizing a bit too soon - before they've had enough development experience to know it's right. but all in all it's fairly well done yet still a bit complex to be truly RISC. 03:17:09 Well, having gone through the specs, from a hw point of view, it's very well thought out, but I occasionally feel like the sw side is a bit of a poor relation; I would really like to see more traffic on standardising the EABI, for example, specifically interrupt requirements and whatnot. I understand that they're very busy, however, and it'll all come in good time. 03:17:40 Having said that, what implementations have taped out are fun to play around with. 03:18:10 As well as adding bits onto the softcores, that is. 03:18:15 proteusguy, I'm a 6800 lover as well 03:18:19 boru ! :) 03:18:26 Afternoon, tp. 03:19:17 afternoon boru, nice to see ya 03:19:40 Likewise. I am not on IRC a lot these last few weeks (and mostly on other nets, at that). 03:20:17 I'm here and on #mecrisp but the traffic is always minimal 03:20:42 Such is the price for high SNR, I guess. 03:21:09 boru, yeah, and in my old age I'm fine with quietitude 03:21:47 Fillies giving you a headache, eh? 03:22:12 boru, nah, Ive been a bachelor the last 5 years 03:22:25 What a productive life you must lead! 03:22:58 yes, it's nice to be free to follow ones own projects without interuption 03:23:27 my Forth progress has been pretty good, for a technician 03:23:47 Well, I'll have a porting project for you soon, I hope. 03:24:25 boru, I'm making up a jig for my next round of copper rivets tomorrow, then I can do a page on the project I'll build with it 03:25:13 basically it's hand wired, deadbugged,two pcb with milled cavities and copper rivets for wired connections 03:25:39 boru, interesting, I cant wait to see it 03:25:55 It'll be finished Soon™ 03:25:59 heheh 03:26:01 yeah 03:26:22 the only thing about being old is it takes 10x longer to do the things I did in my youth 03:28:10 Well, no burning rush. 03:28:35 --- quit: dave0 (Quit: dave's not here) 03:31:05 --- join: iyzsong joined #forth 03:41:07 yeah, all things in time 03:46:55 --- quit: xek_ (Remote host closed the connection) 03:47:16 --- join: xek_ joined #forth 03:50:42 tp: you probably do them now with more quality than you did back in the day though, and that takes extra time and effort. 03:52:23 X-Scale, perhaps, I've been slowly improving all my life, but as a tech I never cut corners, time was always irrelevant to me 03:52:55 X-Scale, I'm sure I used all the thought available to me at the time ;-) 03:59:43 --- join: TCZ joined #forth 04:23:18 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 04:23:58 --- join: iyzsong joined #forth 04:42:30 --- quit: xek_ (Ping timeout: 256 seconds) 04:55:12 --- quit: iyzsong (Ping timeout: 265 seconds) 04:58:26 --- join: iyzsong joined #forth 04:59:27 --- quit: TCZ (Quit: Leaving) 05:27:38 --- join: xek joined #forth 05:50:59 --- quit: Zarutian_HTC (Ping timeout: 264 seconds) 06:12:29 --- quit: ryke (Read error: Connection reset by peer) 06:12:35 --- join: ryke1 joined #forth 06:17:22 --- quit: ryke1 (Ping timeout: 265 seconds) 06:31:47 --- quit: gravicappa (Ping timeout: 264 seconds) 06:40:33 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 06:50:45 --- join: xek_ joined #forth 06:53:28 --- quit: xek (Ping timeout: 260 seconds) 06:59:53 --- nick: xek_ -> xek 07:03:06 --- join: ryke joined #forth 07:07:15 --- join: gravicappa joined #forth 07:27:32 --- quit: jsoft (Ping timeout: 260 seconds) 09:18:16 --- join: WickedShell joined #forth 10:02:49 --- quit: dys (Ping timeout: 240 seconds) 11:21:35 --- quit: Chobbes (Ping timeout: 264 seconds) 11:28:58 --- join: Chobbes joined #forth 11:49:47 --- quit: ryke (Remote host closed the connection) 12:23:32 --- join: TCZ joined #forth 12:31:03 --- join: Zarutian_HTC joined #forth 13:14:39 --- quit: TCZ (Quit: Leaving) 14:23:48 --- quit: xek (Ping timeout: 260 seconds) 15:16:44 --- quit: gravicappa (Ping timeout: 272 seconds) 16:01:47 --- join: dave0 joined #forth 17:06:59 --- quit: JITn (Ping timeout: 246 seconds) 18:07:06 --- join: boru` joined #forth 18:07:09 --- quit: boru (Disconnected by services) 18:07:11 --- nick: boru` -> boru 18:19:21 --- quit: Croran (Remote host closed the connection) 19:10:36 hey guys 19:10:46 hey tabemann 19:11:24 I'm wondering how I'd fit all of zeptoforth in 64K 19:11:41 especially with sector-based flash erasure 19:11:43 why do you have to ? 19:11:59 Zeptoforth runs on a m4 and they have 1MB flash 19:12:01 unless I use the external flash 19:12:34 the chip that numworks uses is an M7 yet it has only 64K of flash onboard 19:12:45 ahh this is regards the numworks 19:13:15 the numworks I am using has 8MB external, but I'd have to figure out how to use that 19:13:42 as no STM32 mcu Im aware off has 1MB flash then perhaps the numworks has to be a special case and use the external flash ? 19:13:52 oops 8MB 19:14:20 the F4 has 1MB internal 19:15:25 hmm, is the external flash serial ? 19:16:35 yes 19:16:47 that might preclude my using it 19:20:28 and that might explain why matthias refused to use it 19:22:23 "refused is a bit strong" he probably just ignored the serial flash a Mecrisp-Stellaris cant use it ? 19:25:18 hmm I'm thinking of how to shrink zeptoforth so that everything, except perhaps the disassembler, can fit in 64K with room to spare 19:26:49 being able to use a external serial flash would be much more useful imo 19:29:01 the key aspect is whether it can be mapped to part of the normal addressing space 19:30:45 i doubt that unless cortex-m has some ability to do that 19:37:39 okay, the Cortex-M7 Supports a Quad SPI interface that can interface with the flash 19:38:13 and map it into the addressing space ? 19:39:49 that's what I gather 19:39:57 it's a general-purpose memory controller 19:40:14 this gets my hopes up that I'll be able to use that 8MB of flash 19:40:19 which'd be awesome 19:40:47 I should look at the flash datasheet to see how it handles erasure 19:40:59 I'm just dl the data sheep now 19:41:03 because if it has small (e.g. 1K or 2K) erase sectors that'd be great 19:41:10 data sheep - lol 19:41:40 https://www.numworks.com/resources/engineering/hardware/electrical/parts/stm32f730-arm-mcu-reference-manual-1b6e1356.pdf 19:42:00 https://www.numworks.com/resources/engineering/hardware/electrical/parts/at25sf641-7d93bee5.pdf 19:42:45 neat it supports 256 byte erasure! 19:43:07 then I'd be able to use flash for blocks after all! 19:43:30 I just have to figure out how to use this memory controller then 19:44:07 and it supports one byte programming! 19:44:21 so no need for padding data for flash 19:44:30 thats pretty cool 19:45:17 so maybe I didn't waste $99.99 on this calculator after all 19:45:57 (even though even with Epsilon it does make a neat calculator) 19:46:15 hang on i have the STM32F412VGT6 listed as the mcu in the numworks 19:46:25 weird 19:46:36 maybe I made a mistake 19:47:29 hmm this page contradicts itself: 19:47:44 https://www.numworks.com/resources/engineering/hardware/electrical/parts/ 19:47:58 on one part of the page it says STM32F730V8T6 19:48:22 on another part of the same page it says STM32F412VGT6 19:48:36 maybe they upgraded it and forgot to update the entire page? 19:49:03 well mecrisp would have been developed on a actual mumworks unit 19:49:25 and Mecrisp-Stellaris lists these binaries 19:49:41 mecrisp-stellaris-numworks-with-sources.bin │ 131072 bytes 19:49:56 thats far more than 64kb 19:50:10 yeah 19:50:19 previous numworks used 1MB of flash 19:50:19 the STM32F412VGT6 must have 1MB ? 19:50:30 must have 19:51:33 youll have to take it apart and look at the pcb 19:51:39 see what is actually in it 19:51:40 ? 19:51:52 I'll trust what that page says 19:52:02 as there's no visible screws on the calculator 19:52:04 so what do you think is in it ? 19:52:43 probably a STM32F730V8T6 because I just bought this calculator 20:05:33 * tabemann is reading Epsilon source code to get a picture of how they interface with flash 20:07:55 hmm 20:08:20 did they change the mcu after Mecrisp-Stellaris made their version for it ? 20:09:07 that's my guess 20:09:41 this Epsilon code uses the MPU for memory regions 20:10:19 all stm32 mcus have a chip type ID in rom 20:12:24 --- quit: reepca (Ping timeout: 260 seconds) 20:17:57 Mecrisp-Stellaris does support the STM F746 Discovery chip = STM32F746NG 20:20:08 --- quit: dave0 (Quit: dave's not here) 20:20:41 --- join: reepca joined #forth 20:20:41 --- quit: reepca (Remote host closed the connection) 20:20:52 --- join: reepca joined #forth 20:22:04 The QUADSPI is a specialized communication interface targeting single, dual or quad SPI 20:22:04 Flash memories. 20:22:04 · memory-mapped mode: the external Flash memory is mapped to the microcontroller 20:22:04 address space and is seen by the system as if it was an internal memory 20:22:15 problem solved :) 20:22:26 the mcu does all the work 20:22:33 yes, that's what I gathered 20:23:00 what I'm wondering is what do I have to do to configure it so it works properly 20:23:59 thats from the STM32F777 manual 20:26:55 the first thing I do is generate a svd2forth from the chip cmsis-svd and have a look 20:27:36 this damn Epsilon code hides everything behind data structures... 20:27:41 like Arduino 20:29:52 --- quit: reepca (Ping timeout: 258 seconds) 20:30:10 it's got 6 SPI peripherals 20:30:24 C loves structures 20:30:47 this is C++ 20:30:54 so they're not like C structs 20:31:00 but rather classes with methods 20:31:15 recently a very experienced engineer on a forum I read claimed that cmsis-svd included "structures of registers" 20:31:29 C thinking is so pervasive 20:32:15 I've programmed over the years in C or C++, like at my last job, yet for something like this I want to see registers and bitfields 20:32:40 for embedded you mean ? 20:33:27 embedded is different to systems programming, C tries to make them the same imho 20:35:45 yeah 20:36:15 what I did was applications programming mostly 20:37:27 thats the mainstream I think 20:37:52 you now have a feel for that embedded difference I imagine 20:38:04 stuff for MRI machines, stuff for printing presses, stuff for simulators for spacecraft instruments - I was for a short bit doing some embedded though, all in C though 20:38:06 looks like one must configure for the SPI memory chip 20:38:56 the thing is I have to figure out how to configure the SPI interface 20:39:00 so your Forth would need a word to configure for the spi at init I guess 20:39:21 thats not going to be too hard once you study the spi chip data 20:39:27 and the mcu config 20:39:33 I find SPI really easy 20:40:09 what you CAN do is load a Forth into the on MCU flash and experiment 20:40:18 thats the whole point of Forth afterall 20:40:34 bbl, off shopping 20:40:39 --- join: reepca joined #forth 21:13:49 --- quit: reepca (Ping timeout: 256 seconds) 21:28:32 --- join: jsoft joined #forth 22:06:05 --- quit: jsoft (Ping timeout: 258 seconds) 22:28:27 --- join: reepca joined #forth 22:37:50 --- join: gravicappa joined #forth 23:23:40 --- join: dys joined #forth 23:52:17 --- join: mtsd joined #forth 23:58:41 --- join: xek joined #forth 23:59:59 --- log: ended forth/20.06.03