00:00:00 --- log: started retro/13.05.12 07:10:28 --- join: ncv (~quassel@unaffiliated/neceve) joined #retro 08:35:06 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #retro 08:39:20 --- quit: kumul (Client Quit) 10:42:06 --- quit: ncv (Remote host closed the connection) 10:49:34 --- join: ncv (~quassel@79.114.78.214) joined #retro 10:49:34 --- quit: ncv (Changing host) 10:49:34 --- join: ncv (~quassel@unaffiliated/neceve) joined #retro 11:21:51 --- quit: ncv (Remote host closed the connection) 11:22:30 --- join: Mat2 (~claude@91-65-144-133-dynip.superkabel.de) joined #retro 11:22:38 hello 11:35:19 --- join: impomatic (~digital_w@43.22.125.91.dyn.plus.net) joined #retro 11:36:17 hi impomatic 11:40:54 I think of an hardware abstraction for block devices. What about an SCSI interface for Ngaro ? 11:42:15 hey mat2 11:42:25 hi tangentstorm ! 11:44:33 Hi Mat2, tangentstorm :-) 11:44:37 probably the more mainstream ATA interface would fit also but there exist so much derivates ATAPI, SATA (both a protocol and interface specification) 11:48:55 or better a general block interface ? 11:49:21 I like the block interface concept. In fact, I've been kind of playing around with that. 11:50:25 https://github.com/sabren/b4/blob/master/go/blockbox.py <- web server so the js implementation could have blocks 11:53:03 the storing one block per file is silly obviously. :) 11:53:24 looks nice. My problem is that I have also hardware implementations in mind. Think of a Ngaro or Saiwa port for the Propeller for example 11:54:50 right... that's not a problem. you're going to need a bunch of implementations of that 11:55:01 one for each platform retro works on. 11:55:17 or at least you could have a bunch of implementations all pointing at the same interface. 11:55:27 using the same interface i mean. 11:56:13 the pro is: Not much effort and portability for the code 11:58:25 implementing an existing hardware-interface as abstraction can give the possibility for supporting wide ranges of devices on the other side 12:09:08 one example: Writing to a SSD block wise is probably not a good idea (beside performance tests) without trimming 12:15:15 Mat2: i've never messed with any of those protocols but in general i like the idea :) 12:15:40 i need blocks for the database i'm working on. i had just planned to use a binary file with fixed size blocks 12:16:49 and for the web it would be nice to fetch blocks over HTTP or a websocket, *or* to cache them locally in localStorage 12:17:53 i think having direct access to the hardware is great ... just it would be nice also have a very highlevel thing that was just "get block, put block, how big are the blocks?" or something 12:19:46 ok, I'm working at current on a simple interface for a compromise. An abstraction hardware near implementable and generic enough so the physical way of storage should be irrelevant 12:21:33 the interface have 8 functions: 12:22:14 INFO : information about all devices accessible and there type 12:22:41 STAT : state of the last accessed device 12:23:07 SYNC: device synchronisation 12:23:23 READ, WRITE: read and write block 12:23:47 TRIM: select block as deleted 12:23:59 what would sync do? 12:25:30 some devices need time for asyncron operations so SYNC signals end-of-processing 12:26:07 CACHE: cache a block in internal memory 12:26:09 gotcha. but doesn't the OUT/WAIT stuff retro provides already kind of do that? 12:28:25 yes, but this functionality is really only needed for block-devices so why depend on a functionality which is implementable at demand though a special port function ? 12:30:10 we would free an instruction for other uses (calling an compiled trace for example) 12:30:22 is SYNC something that the retro program sends to the device? 12:33:46 SYNC is useful for synchronisation of block accesses in environments with some kind of parallel processing 12:34:00 so I found it useful 12:36:48 the functions writes back cached blocks for example if there content is changed 12:38:43 that is the way my old 128 Forth system implemented ram-disks and virtual memory 12:40:25 its simple but efficient (in fact without it a Forth for these old 8-bit computer would be somewhat of limited use) 12:46:36 in this system you always worked with blocks in ram and the interpreter was able to wrote them back or load them independent of there usage. Because accessing a disk-drive is and was a bottleneck this speed up editing a lot and I can't remember a situation where I notice slowdowns 12:49:08 that is also actual for flash devices 12:50:35 another advantage is you can access huge files with very limited ram usage 13:06:52 --- join: crc (~crc@li125-93.members.linode.com) joined #retro 13:11:55 --- quit: impomatic (Ping timeout: 276 seconds) 13:22:31 hi crc 14:06:14 --- join: goingretro (~kbmaniac@host31-51-110-231.range31-51.btcentralplus.com) joined #retro 14:27:21 --- quit: Mat2 (Quit: Verlassend) 14:54:05 --- join: impomatic (~digital_w@43.22.125.91.dyn.plus.net) joined #retro 16:23:22 --- quit: tangentstorm (Ping timeout: 246 seconds) 18:41:05 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #retro 18:47:28 --- quit: tangentstorm (Ping timeout: 260 seconds) 19:03:09 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #retro 19:35:12 --- join: karswell (~user@93-97-29-243.zone5.bethere.co.uk) joined #retro 19:38:15 --- join: karswell` (~user@93-97-29-243.zone5.bethere.co.uk) joined #retro 19:42:41 --- quit: tangentstorm (*.net *.split) 19:47:10 --- quit: karswell (*.net *.split) 19:47:10 --- quit: goingretro (*.net *.split) 19:47:10 --- quit: crc (*.net *.split) 19:48:00 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #retro 19:51:18 --- join: goingretro (~kbmaniac@host31-51-110-231.range31-51.btcentralplus.com) joined #retro 19:51:29 --- quit: tangentstorm (*.net *.split) 19:52:49 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #retro 20:41:08 --- quit: karswell` (Quit: ERC Version 5.3 (IRC client for Emacs)) 20:49:19 --- join: karswell (~user@93-97-29-243.zone5.bethere.co.uk) joined #retro 23:59:59 --- log: ended retro/13.05.12